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FOREWORD 


T}ie  Army  has  recently  fielded  the  first  generation  Tactical  Data  System 
for  the  Field  Artillery — the  Tactical  Fire  Direction  System  (TAO'IRE).  TACFIRE 
is  a  capable  system  but  it  is  recognized  that  this  represents  an  outmoded 
tactical  data  system;  current  technology  has  made  significant  strides  during  the 
development,  testing,  and  fielding  of  this  system.  Advanced  tactical  data 
system  alternatives  are  being  considered  to  modernize  the  Army's  present 
capability  but  these  alternatives  are  likely  to  be  driven  by  hardware  technology 
with  less  thought  given  to  operator/machine  transaction  skills  which  are  diffi¬ 
cult  to  learn  and/or  retain  unless  the  acquisition  cycle  can  be  influenced  in 
its  early  phases.  The  Army  Research  institute  sought  to  develop  a  general 
approach  for  developing  design  concepts  for  later  generations  Field  Artillery 
Tactical  Data  Systems  (FATDS).  The  target  audience  for  this  effort  is  the 
managers  and  management  teams  responsible  for  developing  advanced  FATDS.  This 
report  should  help  to  conceptualize  the  early  design  processes  for  these  systems. 
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Technical  Director 
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EXECUTIVE  SUMMARY 


This  report  describes  a  general  approach  for  developing  design  con¬ 
cepts  for  later  generation  Field  Artillery  Tactical  Data  Systems  (FATDS) . 

The  target  audience  for  this  report  is  the  managers  and  management  teams 
responsible  for  developing  advanced  FATDS.  This  report  will  help  managers 
to  conceptualize  the  early  design  processes  for  these  systems. 

It  was  determined  that  trade-off  analyses  among  alternative  concept 
designs  for  a  system  can  not  be  developed  and  applied  usefully  without  first 
specifying  the  characteristics  of  the  inputs  to  the  trade-off  analysis,  how 
those  inputs  are  to  be  developed,  and  how  the  outputs  from  the  trade-off 
analysis  are  to  be  used  to  further  the  development  of  the  system  design. 

The  management  approach  described  in  this  report  distinguishes  the  concept 
design  of  a  system  from  its  engineering  design.  It  includes  procedures  for 
developing  alternative  concept  designs,  for  conducting  trade-off  analyses 
among  the  alternatives,  and  for  integrating  the  better  features  of  the 
non-selected  alternatives  into  the  selected  alternative.  The  output  from 
this  approach  provides  the  basis  for  the  engineering  design  of  the  emerging 
system. 

The  Concept  Design  Management  Approach  (CDMA)  described  in  this  report 
is  characterized  by  eleven  significant  features: 

1.  It  is  a  rational  approach  for  developing  the  design  concept 
for  a  FATDS.  It  consists  of  two  major  processes: 

a.  A  front  end  analysis  process  (1)  which  collects  or  generates 
information  about  the  environments  and  situations  in  which 
the  FATDS  will  operate,  (2)  which  identifies  the  response 
demands  which  must  be  met  by  the  FATDS,  and  (3)  which 
specifies  the  minimum  human  role  which  must  be  supported 

by  the  system. 

b.  A  design  concept  process  (1)  which  allocates  information 
processing  activities  in  the  emerging  system  concept  to 
human  or  machine  components  and  (2)  which  specifies  the 
interface  characteristics  required  to  support  mental 
information  processing  of  commanders  and  operators  of  the 
FATDS. 

2.  It  conceives  of  a  FATDS  (or  any  C3  system)  as  being  an  information 
processing  system  performed  both  by  machine  and  human  components. 

3.  It  provides  a  general  cognitive  model  for  insuring  at  least  a 
minimum  role  for  humans  as  commander/monitor  of  the  system. 

This  model  provides  guidance  for  analyzing  the  activities  which 
make  up  this  role. 
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4.  It  encourages  the  consideration  of  established  technologies, 
state-of-the-art  technologies,  and  foreseeable  technologies 
to  insure  that  the  resulting  system  concept  is  not  outmoded 
by  the  time  the  system  is  fielded. 

5.  It  identifies  the  various  kinds  of  human  judgments  that  need 
to  be  made  in  developing  a  design  concept  for  a  FATDS. 

6.  It  identifies  the  characteristics  of  personnel  best  suited  for 
making  each  kind  of  judgment. 

7.  It  specifies  particular  group  process  techniques  for  obtaining 
the  best  possible  judgments  from  the  appropriate  personnel. 

These  techniques  provide  for  the  mixing  of  personnel  with 
different  qualifications  in  each  group  so  that  each  can  bring 
his  or  her  own  special  qualifications  to  bear  on  the  judgments 
in  an  optimum  manner. 

8.  It  specifies  techniques  for  assigning  numeric  values  to  judgments 
and  for  aggregating  judgments  from  different  raters.  The 
aggregation  procedures  allow  for  the  introduction  of  differential 
weights  which  reflect  management  interests  and  criteria. 

9.  It  specifies  trade-off  techniques  for  using  the  numeric  values 
assigned  to  judgments  regarding  the  impact  of  alternative 
concepts  on  critical  factors  for  selecting  the  best  of  several 
alternative  design  or  interface  concepts. 

10.  It  specifies  techniques  for  using  the  numeric  values  assigned 
to  judgments  regarding  the  impact  of  a  design  or  interface  con¬ 
cept  on  critical  factors  for  improving  the  concept. 

11.  It  provides  a  basis  for  developing  a  detailed  audit  trail  of  the 
entire  design  concept  process. 

The  approach  described  in  this  report  offers  the  design  management  team 
a  number  of  attractive  benefits: 

1.  It  provides  a  rational  and  fully  described  approach  which  can 
either  be  incorporated  into  the  project  intact  or  used  as  a  first 
approximation  in  developing  their  own  fully  explicated  approach. 

The  CDMA  is  very  flexible  and  can  be  readily  adapted  to  meet 
specialized  needs  and  interests. 

2.  It  provides  a  division  of  activities  that  can  be  used  for 
measuring  progress  and  making  assignments. 


3.  Lt  provides  a  basis  for  project  stability  even  through  major 
personnel  changes.  New  personnel  can  readily  review  the  audit 
trail  of  past  activities  and  the  projection  of  future  activities. 

4.  Lt  provides  assurance  that  the  design  concept  that  evolves  from 
the  application  of  the  approach  is  the  best  that  could  be 
developed  at  that  time  with  the  personnel  and  resources  available. 

At  this  time,  the  CDMA  exists  more  as  a  very  detailed  proposal  since  it 
has  not  actually  been  tried  out  as  an  intact  process.  A  tryout  would  help 
develop  or  firm  up  details  in  the  process.  However,  all  of  its  features 
are  drawn  from  established  behavioral  science  technology.  There  is  no  doubt 
about  it  being  a  workable  process,  but  adjustments  will  be  needed  during 
its  early  applications. 
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INTRODUCTION 


BACKGROUND 

The  U.S.  Army  Field  Artillery  Branch  has  fielded  its  first  generation 
tactical  data  system — TACFIRE.  Hybrid  and  second  generation  systems  are 
already  being  considered.  During  the  next  two  decades,  there  will  probably 
be  a  series  of  design  and  development  efforts  concerned  with  improving  the 
existing  TACFj-RE  system  and  with  supplanting  it  in  time  with  highly  advanced 
tactical  data  systems.  This  report  describes  a  concept  for  a  general  design 
process  for  developing  improved  or  new  tactical  data  systems.  This  design 
process  emphasizes  the  design  of  systems  (1)  that  will  meet  the  battlefield 
needs  for  which  they  are  designed  and  (2)  that  optimize  usability  of  the 
system  by  operators  and  commanders.  This  design  process  is  intended  to  be 
used  by  concept  developers  and  system  designers  in  structuring  potential 
replacements  for  TACFIRE. 


Command,  Control,  and  Communication  (C3)  Systems 

The  system  design  process  described  in  this  report  is  sufficiently 
general  to  be  applied  to  the  design  of  systems  other  than  field  artillery 
tactical  data  systems.  It  is  more  broadly  applicable  to  the  design  of 
almost  any  command,  control,  and  communication  (C3)  system  for  either 
military  or  industrial  uses. 

A  tactical  data  system  is  an  information  processing  system.  It 
coordinates  command,  control,  and  communication  (C3)  activities  within 
some  larger  system.  The  Field  Artillery  Tactical  Data  System  (FATDS) 
coordinates  information  and  decision  flow  within  the  larger  Field  Artillery 
system  in  a  battlefield  environment  J^o  help  accomplish  the  larger  system' s 
missions . 


A  Common  Mistake  in  the  Design  of  C3  Systems 

The  rapid  development  of  powerful,  automatic  information  processing 
technologies  has  led  to  a  situation  in  which  hardware  technology  has  be¬ 
come  the  "driver"  in  the  development  of  military  and  industrial  C3  systems. 
Functions  have  been  relegated  to  the  computer  without  much  regard  to  the 
machine's  actual  capabilities  or  to  human's  information  processing  role 
in  the  larger  system.  The  initial  effort  is  focused  on  the  design  of  fully 
automated  systems.  Later,  when  it  is  discovered  that  the  C3  system  cannot 
function  fully  automatically,  humans  are  "retrofitted"  into  the  system  to 
perform  the  functions  that  the  machine  cannot  perform. 
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Recently,  thoughtful  people  in  the  military  development  community 
have  come  to  the  realization  that  a  more  considered  approach  to  the  develop¬ 
ment  of  C3  systems  is  required.  A  fully  automatic  system  probably  cannot 
exist.  At  the  very  least,  humans  will  always  have  a  monitoring  and  possible 
override  role  in  the  system.  Monitoring  is  not  a  passive  process:  Rather, 
it  is  a  highly  active  process  in  which  the  monitor  builds  and  checks  ex¬ 
pectations  about  activities  in  the  larger  system  and  makes  decisions  about 
deviations  from  those  expectations.  Humans,  as  operators  or  commanders, 
must  always  be  part  of  any  C3  system.  There  is  a  need  for  design  processes 
which  include  humans  as  integral  parts  of  the  system  from  the  inception  of 
the  design  rather  than  "putting  man  into  the  loop"  as  an  afterthought. 

The  Need  for  a  New  Focus  in  Human  Factors  Technology 

In  a  human-machine  system,  the  machine's  displays  and  controls  make  up 
the  interfaces  by  which  transactions  between  human  and  machine  occur.  In 
the  past  two  or  three  decades,  human  factors  scientists  and  engineers  have 
developed  a  technology  for  designing  human-machine  interfaces  that  minimize 
discrimination  and  action  errors  by  operators  (e.g.,  McCormick,  1976).  This 
is  a  necessary  but  not  sufficient  technology  for  designing  effective  human- 
machine  interfaces  for  C3  systems. 

C3  systems  involve  humans  at  least  as  monitors  and  high  level  decision 
makers  about  some  remote  process — actions  in  a  distant  battlefield  or  air 
space,  conditions  in  a  distant  industrial  process,  and  the  like.  The  roles 
of  human  beings  require  them  to  function  as  complex  information  processors 
in  a  complex  information  processing  system.  There  is  a  need  for  a  design 
process  that  allocates  information  processing  functions  which  need  to  be 
accomplished  by  the  system  to  its  two  major  components,  human  and  machine, 
on  the  basis  of  which  can  best  perform  each  function.  Best  in  this  usage 
is  defined  in  terms  of  the  overall  effectiveness  of  the  larger  system. 
Furthermore,  the  human-machine  interfaces  should  be  designed  to  support  the 
functions  assigned  to  humans  and  the  functions  that  make  up  human's  monitor¬ 
ing  and  override  roles.  The  interfaces  should  select,  organize,  and  display 
information  to  the  operator/commander  in  such  a  manner  as  to  facilitate  his 
or  her  own  thinking  about  the  remote  process  no  matter  how  "automatic"  the 
machine  might  be. 

With  regard  to  automated  industrial  plants,  Rasmussen  and  Lind  (1981) 
observe : 

For  industrial  plants,  the  complexity  faced  by  operators  is 
determined  by  the  representation  of  the  internal  state  of  the 
system  which  the  interface  allows  the  operator  to  develop  for 
the  various  work  conditions ... (G) reat  care  should  be  taken  when 
a  computer  is  used  to  generate  displays  in  order  to  match  the 
representation  used  for  displays  to  the  operators'  preferred 
work  strategies  and  understanding  of  the  processes.  If  this 
match  is  not  successful,  operators  may  be  left  with  the  even 
more  complex  situation  of  having  to  evaluate  the  information 
processes  of  the  computer. 


These  authors  present  a  general  model  of  the  total  data  processing  task. 

(This  model  is  greatly  expanded  in  the  general  cognitive  model  described 
in  the  third  phase  of  the  front-end  analysis  in  this  report.)  They  further 
observe : 

Since  the  human  capacity  for  analysis  and  decision  in  a 
non-routine  situation  is  notoriously  limited  to  consideration 
of  a  very  limited  number  of  items,  the  only  way  to  cope  with 
the  high  number  of  information  sources  and  devices  of  elementary 
actions  (e.g.,  switches  and  valves)  found  in  an  industrial  plant, 
is  to  structure  the  situation  and  to  transfer  the  problem  to  a 
representation  at  a  level  with  less  resolution.  The  total  data 
processing  task  then  is:  To  structure  the  information  at  a  higher 
level  representation  of  the  states  of  the  system;  to  make  a 
choice  of  intention  at  that  level;  and  then  to  plan  the  sequence 
of  detailed  acts  which  will  suit  the  higher  level  intention  .  .  . 

There  is  a  need  for  a  human  factors  technology  (1)  which  provides  a  basis 
for  optimum  allocation  of  information  processing  functions  to  human  or 
machine  and  (2)  which  provide  interfaces  whose  information  representations 
match  the  natural  representations  used  by  operators  and  commanders  in  their 
thinking  about  the  states  of  the  system  and  the  remote  processes  under  their 
control.  The  system  design  process  described  in  this  report  is  a  first  step 
in  the  development  of  such  a  human  factors  technology.  In  its  initial  fora, 
this  design  process  depends  heavily  upon  human  judgment  based  on  the  best 
available  experience.  As  this  technology  develops,  research  should  provide 
tested  information  to  replace  some  of  the  requirements  for  human  judgment, 
but  human  judgment  will  always  remain  a  substantial  part  of  the  design  process. 


THE  PROBLEM 

The  initial  objective  of  this  project  was  to  do  a  trade-off  analysis 
among  existing  alternative  FATDS  concept  designs.  However,  it  was  believed 
that  the  existing  alternative  concept  designs  were  not  sufficiently  well 
specified  to  allow  them  to  be  entered  directly  into  a  trade-off  matrix. 

This  condition  was  believed  to  exist,  in  part,  because  the  development  process 
used  for  defining  the  concept  design  alternatives  was  not  concerned  with 
preparing  inputs  for  entry  into  a  trade-off  procedure  and,  in  part,  because 
there  was  not  a  clear  distinction  between  the  concept  design  of  the  system 
and  its  engineering  design.  It  was  thought  that  trade-off  procedures  cannot 
be  reasonably  applied  without  specifying  the  characteristics  of  the  inputs 
to  the  trade-off  and  without  specifying  how  the  outputs  from  the  trade-off 
were  to  be  used;  that  is,  without  specifying  the  development  context  in  which 
the  trade-off  occurs.  For  these  reasons,  it  was  decided  to  formulate  a  total 
management  approach  for  developing  the  concept  design  of  a  FATDS  which  in¬ 
cludes  the  definition  of  alternative  trial  concept  designs  and  their  entry 
into  a  trade-off  procedure  which  provides  the  basis  for  the  engineering  de¬ 
sign  of  the  emerging  system. 
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AN  OVERVIEW  OF  THE  DESIGN  PROCESS 

A  C3  system  is  an  information  processing  system  which  coordinates 
command,  control,  and  communication  functions  in  some  larger  system.  Hence, 
the  design  of  the  C3  system  must  be  based  on  a  description  of  the  larger 
system.  This  description  of  the  larger  system  establishes  what  kinds  of 
information  are  to  be  processed  towards  what  goals  and  what  kinds  of  re¬ 
sponse  demands  the  larger  system  places  on  the  C3  system  in  order  to  meet 
the  goals  of  the  larger  system.  The  response  demands  imposed  by  the  larger 
system  specify  the  information  processing  functions  required  of  the  C3 
system,  the  range  of  information  loads  that  it  must  be  able  to  handle,  and 
the  speed  and  accuracy  with  which  it  must  respond.  These  response  demands 
for  the  C3  system  in  turn  are  derived  in  part  from  the  response  demands 
imposed  on  the  larger  system  by  the  environment  and  situations  in  which 
it  operates. 

The  concept  design  management  approach  (CDMA)  is  divided  into  two 
major  stages: 

1.  The  front-end  analysis. 

2.  The  design  and  decision  process. 

The  front-end  analysis  determines  the  situations  in  which  the  C3  system 
must  operate  and  the  demands  it  must  meet.  The  design  and  decision  process 
develops  a  concept  of  the  C3  system  in  terms  of  hardware,  software,  and  be¬ 
havioral  technologies  that  meets  the  demands  identified  in  the  first  stage. 

A  field  artillery  system  can  operate  in  many  different  environments 
and  in  many  different  situations  in  those  environments.  The  field  artillery 
system  may  well  require  different  characteristics  to  function  optimally  in 
these  different  environments  and  situations.  These  different  environments 
and  situations,  and  the  characteristics  of  the  larger  system  may,  in  turn, 
impose  different  functional  requirements  and  different  response  demands  on 
the  C3  system.  Hence,  the  description  of  the  larger  system  must  include  a 
description  of  the  environments  and  situations  in  which  the  system  is  ex¬ 
pected  to  operate  and  a  description  of  the  larger  system's  components  and 
functions  required  to  accomplish  its  goals  in  the  expected  environments  and 
situations.  The  development  of  these  descriptions  constitutes  the  first 
part  of  the  first  phase  in  the  front-end  analysis  for  a  FATDS.  It  is  quite 
likely  that  most  or  all  of  these  descriptions  already  exist  or  at  the  very 
least  that  the  information  base  for  developing  them  already  exists. 

The  second  part  of  the  first  phase  of  the  front-end  analysis  consists 
of  specifying  the  response  demands  imposed  upon  the  FATDS  by  the  larger 
system.  The  response  demands  are  derived  from  an  analysis  of  the  performance 
of  the  larger  system  in  the  expected  environments /situations .  In  order  to 
establish  response  time  demands,  the  results  of  this  analysis  will  have  to 
be  represented  on  a  time  line;  that  is,  the  likely  time  required  to  perform 
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each  activity  will  have  to  be  estimated  and  these  estimates  will  have  to 
be  recorded  as  part  of  the  description  and  aggregated  across  the  activities 
required  for  effective  performance  in  each  expected  environment/situation . 

Once  the  expected  environments  and  situations  in  which  the  field  ar¬ 
tillery  system  will  operate  have  been  described  and  once  the  larger  system 
itself  has  been  described,  including  its  goals,  functions,  and  components, 
then  the  conceptual  description  of  the  FATDS  can  begin.  The  initial  con¬ 
ceptualization  of  the  FATDS  (C3)  system  must  be  in  terms  of  its  information 
processing  functions.  This  is  the  essence  of  the  system. 

The  second  phase  of  the  front-end  analysis  consists  of  describing  the 
functions  that  comprise  the  information  flow  leading  to,  through,  and  from 
the  FATDS.  These  descriptions  are  developed  for  each  expected  environment/ 
situation  in  which  the  larger  system  is  to  be  able  to  perform. 

The  third  phase  insures  that  humans  are  built  into  the  conceptual  de¬ 
sign  of  the  system.  At  the  very  least,  humans  will  perform  the  role  of 
monitoring  the  operation  of  the  FATDS  and,  if  necessary,  overriding  some 
of  the  automatic  functions  built  into  it.  The  information  processing  func¬ 
tions  required  to  perform  this  role  in  each  expected  environment/situation 
in  which  the  larger  system  will  operate  need  to  be  identified.  This  phase 
ends  the  front-end  analysis  process. 

In  the  first  phase  of  the  design  and  decison  process,  the  information 
processing  functions  identified  in  the  latter  part  of  the  front-end  analysis 
are  allocated  to  either  human  or  machine  components  of  the  emerging  FATDS 
conceptualization.  Criteria  for  allocating  functions  to  human  or  machine 
components  are  derived  from  the  state  of  equipment  technologies.  Several 
sets  of  these  criteria  can  be  developed  to  reflect  different  degrees  of 
technological  risk.  For  instance,  one  set  of  criteria  may  be  based  on 
well-established  technology,  another  set  may  be  based  on  state-of-the-art 
technology,  and  a  third  set  might  be  based  on  foreseeable  future  technology. 
These  different  levels  of  technology  will  lead  to  the  development  of  several 
alternative  allocations  of  information  processing  functions.  For  instance, 
a  function  that  cannot  be  performed  adequately  by  a  machine  today  might  well 
be  performable  by  a  machine  in  the  foreseeable  future. 

A  consideration  of  these  different  levels  of  technological  development 
is  important  for  several  reasons.  Expected  environments/situations  will 
generally  be  based  on  projections  into  the  future — likely  international 
developments,  likely  technological  developments  by  potential  enemies,  and 
so  on.  Established  technology  may  not  be  capable  of  meeting  the  response 
demands  resulting  from  such  developments.  Hence,  it  will  be  necessary  to 
make  similar  projections  about  the  development  of  new  technology.  It  may 
be  necessary  to  develop  one  or  more  new  technologies  before  an  effective 
FATDS  can  be  conceptualized.  Certainly,  it  is  not  desirable  to  invest  re¬ 
sources  into  a  conceptualization  that  could  not  meet  the  response  demands 


for  effective  performance  on  the  battlefield  at  the  time  it  was  fielded  or 
very  shortly  thereafter.  Nor  is  it  desirable  to  believe  that  an  inadequate 
conceptualization  would  work. 

In  the  second  phase  of  the  design  and  decision  process,  the  interfaces 
for  matching  the  machine's  information  representations  to  the  human's  in¬ 
formation  representations  involved  in  each  human-machine  transaction  are 
designed.  Again,  there  is  a  choice  among  established  technologies,  state- 
of-the-art  technologies,  and  foreseeable  technologies.  These  levels  of 
technology  lead  to  the  development  of  several  alternative  design  concepts 
for  the  human-machine  interfaces.  In  fact,  several  design  concepts  might 
be  developed  within  a  given  level  of  technology.  For  instance,  several 
different  foreseeable  technological  developments  may  be  able  to  transmit 
the  same  kind  of  information  across  an  interface. 

The  second  phase  of  the  design  and  decision  process  completes  the 
conceptual  design  of  a  FATDS.  This  conceptual  design  consists  of  an  alloca¬ 
tion  of  information  processing  functions  to  human  and  machine  components, 
an  identification  of  appropriate  technology  for  accomplishing  each  machine 
function,  a  specification  of  the  machine’s  information  processing  repre¬ 
sentations  in  each  human-machine  transaction,  and  an  identification  of 
appropriate  technology  for  establishing  these  representations.  This  con¬ 
ceptualization  provides  a  basis  for  identifying  technological  developments 
required  for  development  of  the  FATDS  and  for  projecting  a  reasonable 
schedule  for  development  of  the  FATDS. 

The  overview  of  the  process  would  not  be  complete  without  briefly 
describing  the  trade-off  procedure  for  selecting  among  the  alternative 
design  concepts  in  the  two  phases  of  the  design  and  decision  process. 

There  are  many  attributes  to  consider  in  placing  a  value  on  an  alternative 
design  in  order  to  compare  it  to  other  alternatives.  Consequently,  the 
procedure  that  is  used  is  an  application  of  multiattribute  utility  tech¬ 
nology  (MAUT).  (For  example,  see  Keeney  &  Raiffa,  1976.)  It  facilitates 
decision  making  by  identifying  and  weighting  all  the  design  impact  factors 
(DIFs)  of  the  stakeholders  in  the  decision.  The  DIFs,  in  this  application, 
are  concerned  with  the  demands  and  resources  for  developing  a  FATDS.  The 
procedure  consists  of  obtaining  judgments  on  each  of  various  relevant  fac¬ 
tors  and  weights  for  these  factors  from  the  most  knowledgeable  sources 
for  each  judgment.  The  judgments  and  weights  are  then  aggregated  in  var¬ 
ious  ways  to  provide  figures  of  merit  for  different  parts  of  an  alternative 
conceptualization  and  for  different  alternative  conceptualizations.  Com¬ 
parison  of  appropriate  figures  of  merit  provides  a  rational  means  for  im¬ 
proving  a  conceptualization  and  for  selecting  among  alternative  conceptualiza¬ 
tions. 

In  summary,  the  approach  described  in  this  report  consists  of  two 
stages  composed  of  a  total  of  five  phases,  as  follows: 
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STAGE 

1. 

2. 

3. 

STAGE 

1. 

2. 


.  FRONT-END  ANALYSIS: 

Describe  the  larger  system;  i.e.  ,  field  artillery  in  the 
battlefield.  Specify  the  response  demands  imposed  by  the 
larger  system  on  the  FATDS  (C^  system). 

Describe  the  information  flow  leading  to,  through,  and 
from  the  FATDS  (C^  system). 

Analyze  human’s  monitoring  and  possible  override  role  in 
the  FATDS. 

.  DESIGN  AND  DECISION  PROCESS 

Allocate  information  processing  activities  to  human  or 
machine.  Alternative  information  processing  concepts 
are  developed  in  this  stage. 

Develop  interface  designs  that  provide  human  commander/ 
operators  with  as  close  a  representation  as  possible  to 
their  own  information  processing  representations  in  each 
human-machine  transaction.  Alternative  interface  concepts 
are  developed  in  this  stage. 


The  second  stage  applies  a  multiattribute  decision  making  procedure  for 
selecting  among  alternative  conceptualizations  and  for  improving  the 
selected  conceptualization. 


STAGE  ONE:  FRONT-END  ANALYSIS 


The  front-end  analysis  determines  the  situations  in  which  the  C3 
system  (or  FATDS)  must  operate  and  the  demands  it  must  meet. 


PHASE  ONE:  DESCRIBE  THE  LARGER  SYSTEM. 

The  outcomes  of  this  phase  will  be:  (1)  a  description  of  the  opera¬ 
tion  of  our  own  field  artillery  system  in  battlefield  situations  in  the 
particular  environments  of  most  concern  to  us,  (2)  an  identification  of 
episodes  in  those  situations  which  are  most  relevant  to  the  design  of  a 
FATDS,  and  (3)  a  specification  of  the  response  demands  imposed  by  the  larger 
system  upon  the  FATDS  in  the  relevant  battlefield  episodes. 

This  phase  consists  of  eight  steps: 

1.  Identify  the  target  period. 

2.  Identify  the  probable  weapon  characteristics  and  the  probable 
tactics  of  both  friendly  ane  enemy  forces  during  the  target 
period. 

3.  Develop  categories  of  characteristics  that  will  provide  as  broad 
an  identification  of  environments  and  situations  as  possible. 

4.  Develop  and  apply  an  elimination  strategy. 

5.  Define  environments  and  situations  by  combining  detailed 
characteristics  from  separate  categories. 

6.  Develop  action  scenarios  for  each  environment/situation. 

7.  Identify  episodes  in  each  action  scenario  that  are  significant 
to  the  operation  of  FATDS. 

8.  Identify  the  response  demands  imposed  by  the  larger  (artillery) 
system  on  the  FATDS. 


Step  1.  Identify  the  target  period 

The  first  step  in  this  phase  is  to  identify  the  target  period.  This 
period  must  be  projected  far  enough  into  the  future  to  allow  the  time 
necessary  to  develop,  produce,  and  field  a  FATDS,  but  not  so  far  that  sig¬ 
nificant  periods  of  national  threat  are  overlooked.  Weighing  these  two  sets 
of  concerns  in  the  selection  of  a  target  period  requires  a  decision  from  very 
high  policy  making  levels.  This  period  establishes  our  tentative  target 
date  for  fielding  the  system. 
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Step  2.  Identify  the  probable  weapon  characteristics  and  the  probable 
tactics  of  both  friendly  and  enemy  forces  during  the  target  period 

The  second  step  is  to  identify  the  probable  weapon  characteristics  and 
probable  tactics  for  enemy  forces  and  for  our  own  forces  during  the  target 
period.  Descriptions  should  be  prepared  of  the  probable  deployment  patterns 
that  will  be  used  by  the  enemy  forces  and  by  our  own  forces.  Next,  a  listing 
of  the  general  objectives  relevant  to  each  type  of  deployment  should  be 
developed.  For  instance,  general  objectives  for  field  artillery  might 
include  statements  such  as: 

Deliver  appropriate,  accurate,  and  timely  fire  in  response 
to  fire  requests. 

Deliver  appropriate,  accurate,  and  timely  fire  according  to 
higher  level  fire  plan. 

Deliver  appropriate,  accurate,  and  timely  counterfire. 

Avoid  delivering  fire  on  friendly  forces. 

These  general  objectives  determine  how  an  engagement  from  a  given  deployment 
is  likely  to  develop.  They  guide  the  selection  of  appropriate  actions. 

The  information  developed  in  the  first  two  steps  probably  already  exists. 
It  is  a  necessary  information  bast  for  almost  any  kind  of  future-oriented 
military  preparation. 


Step  3.  Develop  categories  of  characteristics  that  will  provide  as  broad 
an  identification  of  environments  and  situations  as  possible 

The  third  step  begins  the  identification  of  specific  environments  and 
situations.  It  is  important  to  at  least  consider  every  possible  relevant 
environment  and  situation.  Failure  to  do  so  could  lead  to  the  development 
of  a  FATDS  that  cannot  function  effectively  in  some  potentially  critical 
environment  or  situation.  One  way  of  Insuring  that  all  possible  situations 
are  considered  is  to  conduct  a  situation  identification  analysis  (McKnight  & 
Adams,  1972).  A  situation  identification  analysis  proceeds  in  four  phases. 

In  the  first  phase,  hierarchies  of  successively  more  specific  characteristics 
for  defining  situations  and  environments  are  identified.  In  the  second  phase, 
a  strategy  is  developed  for  eliminating  those  combinations  of  characteristics 
that  are  least  relevant.  In  the  third  phase,  relevant  combinations  of  char¬ 
acteristics  are  formed  to  identify  the  environments/situations  in  which  the 
FATDS  will  operate,  scenarios  are  prepared  for  each  environment/situation, 
and  specific  FATDS-relevant  episodes  are  identified  in  each  scenario.  And 
in  the  fourth  phase,  judgments  are  made  about  the  importance  and  frequency 
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of  the  final  episodes  as  a  means  of  reducing  the  number  that  will  be 
analyzed  in  the  next  phase  of  the  CDMA.  The  second  and  fourth  phases 
are  included  to  reduce  the  final  number  of  episodes  to  only  those  which 
are  most  meaningful.  For  instance,  if  each  situation  were  defined  by  a 
combination  of  five  characteristics  drawn  from  five  dimensions  or  cate¬ 
gories  (r)  with  an  average  of  ten  characteristics  or  values  (n)  for  each 
dimension,  then  it  would  be  possible  to  define  n  =  10  =  100,000  different 

situations.  Clearly,  some  simplification  is  needed.  The  third,  fourth, 
fifth,  sixth,  and  seventh  steps  of  the  description  of  the  larger  system 
correspond  to  the  four  phases  of  situation  identification  analysis.  (The 
third  phase  corresponds  to  two  steps  in  the  analysis.) 

The  objective  of  the  third  step  is  to  develop  categories  of  character¬ 
istics  that  will  provide  as  broad  an  identification  of  environments  and 
situations  as  possible.  This  is  accomplished  by  applying  a  general  to 
specific  strategy  for  identifying  successively  more  specific  environment 
and  situation  characteristics.  First,  identify  the  broad  categories  of 
relevant  environment  and  situation  descriptors.  At  the  highest  level, 
environment  categories  would  include  terrain  and  weather.  Situation  char¬ 
acteristics  would  include  enemy  forces,  own  forces,  and  military  context. 
Next,  break  each  of  these  broad  categories  down  into  smaller  categories. 

For  instance,  terrain  might  be  broken  into  types  of  surfaces,  types  of 
ground  cover,  significant  natural  features,  and  significant  human  artifacts. 
Enemy  forces  and  own  forces  might  be  broken  down  into  strength,  re-supplv 
conditions,  and  intelligence  capabilities.  Military  context  might  be  broken 
into  military  state  (stalemate  conditions,  own  frontal  push,  enemy  frontal 
push),  supply  state,  and  the  like.  Each  of  these  smaller  categories  would 
then  be  broken  into  still  smaller  categories.  For  instance,  types  of  terrain 
could  be  broken  into  tundra,  desert,  tropical  forest,  wooded  hills,  and  so 
on.  Strength  of  own  and  enemy  forces  might  be  broken  down  into  weaponry, 
and  personnel.  Each  level  of  division  should  break  the  next  higher  level 
into  two  to  seven  smaller  categories.  Each  category  is  broken  down  until 
a  level  is  reached  with  adequately  detailed  characteristics  to  allow  unam¬ 
biguous  specification  of  how  a  military  engagement  in  a  given  environment 
and  situation  might  proceed.  Different  categories  can  be  broken  down  to 
different  levels.  The  breakdowns  don’t  have  to  be  uniform  throughout. 

This  analysis  results  in  the  development  of  a  hierarchy  of  environmental 
and  situational  characteristics.  The  structure  of  such  a  set  of  character¬ 
istics  is  shown  in  Figure  1. 


Step  4.  Develop  and  apply  an  elimination  strategy 

In  the  fourth  step ,  a  strategy  is  developed  for  eliminating  certain 
combinations  of  characteristics  from  consideration.  The  first  part  of  the 
strategy  consists  of  examining  general  categories  of  characteristics  in 
combination  with  one  another  before  addressing  them  at  the  level  of  individual 
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characteristics.  Some  combinations  of  general  categories  may  be  unimportant 
or  may  not  make  sense.  In  such  cases,  there  will  be  no  need  to  examine  com¬ 
binations  of  individual  characteristics  from  the  two  categories.  Such  com¬ 
binations  of  individual  characteristics  can  be  eliminated  from  consideration. 
The  second  part  of  the  strategy  restricts  the  number  of  categories  from  which 
characteristics  are  drawn  in  identifying  situations.  For  instance,  suppose 
a  hierarchy  contained  five  categories  of  characteristics  with  an  average 
of  five  characteristics  in  each  category.  Taking  one  characteristic  from 
each  of  the  five  categories  to  identify  each  situation  would^lead  to  the 
possible  identification  of  3125  different  situations  (n  =  5  =  3125).  How¬ 

ever,  if  each  situation  was  identified  by  only  three  characteristics — one 
taken  from  each  of  three  different  categories,  then  the  number  of  possible 
situations  would  only  be  1250  (10  combinations  of  5  categories  taken  3  at  a 
time  multiplied  by  5  characteristics  raised  to  the  third  power  for  the  three 
categories  used  to  define  each  situation).  The  same  total  number  of  char¬ 
acteristics  divided  into  a  few  categories  will  produce  fewer  combinations 
than  if  they  were  divided  into  a  larger  number  of  categories.  In  general, 
it  won't  bo  meaningful  to  draw  characteristics  from  more  than  three  different 
categories  to  form  situation  defining  situations. 

The  first  part  of  the  elimination  strategy  removes  general  categories 
of  combinations  of  characteristics.  The  second  part  of  the  elimination 
strategy  restricts  the  number  of  categories  that  are  used  to  define  situations. 


Step  5.  Define  environments  and  situations  by  combining  detailed 
characteristics  from  separate  categories 

In  the  fifth  step,  detailed  characteristics  from  different  categories 
are  combined  to  define  situations.  For  instance,  an  environment  might  be 
specified  by  the  following  detailed  characteristics:  tundra  terrain  and 
daily  temperatures  below  freezing.  A  situation  might  be  specified  by  the 
following  detailed  characteristics:  enemy  armored  division,  friendly  armored 
division,  no  significant  human  artifacts  in  area  (that  is,  no  roads,  bridges, 
towns,  and  so  on),  enemy  mounting  frontal  push,  enemy  has  difficult  re¬ 
supply,  and  so  on.  Next,  the  list  of  environments  and  the  list  of  situations 
generated  in  this  way  is  examined  and  judgments  are  made  about  the  importance 
and  frequency  of  each  entry  in  each  list.  Only  the  more  important  and/or  more 
frequent  entries  need  to  be  retained.  At  this  point,  the  objective  is  to 
reduce  the  list  to  the  most  representative  combinations  that  can  in  fact  be 
analyzed  with  the  resources  available.  In  this  analysis,  the  next  part  of 
this  step  forms  meaningful  combinations  of  environments  and  sit  uations. 

These  environment/situation  combinations  can  be  clustered  on  the  basis  of 
the  similarity  of  the  actions  most  likely  to  occur  in  each.  This  step  ends 
with  a  clustered  list  of  relevant  environments/situations  for  the  selected 
target  period. 
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Step  6.  Develop  action  scenarios  for  each  environment/situation 


In  the  sixth  step  action  scenarios  are  developed  for  each  relevant 
environment/situation.  An  action  scenario  is  basically  a  listing  of  the 
events  that  transpire  as  the  situation  develops.  The  events  in  the  sce¬ 
nario  should  be  listed  on  a  time  line  with  as  accurate  time  estimates  as 
possible.  The  events  can  be  presented  in  list  form,  in  a  component  (unit) 
by  time  period  matrix,  or  in  a  parallel  flowchart. 

A  component  by  time  period  matrix  is  illustrated  in  Figure  2.  Each 
enemy  and  friendly  unit  is  assigned  a  different  row  in  the  matrix.  The 
scenario  is  broken  into  time  periods  and  each  time  period  in  order  is 
assigned  to  a  different  column  of  the  matrix.  The  action  performed  by  each 
unit  in  each  time  period  is  described  and  entered  into  the  appropriate  cell 
of  the  matrix.  A  parallel  flowchart  is  illustrated  in  Figure  3.  A  parallel 
1 lowchart  is  similar  to  a  component  by  time  period  matrix  in  that  each  unit 
is  assigned  to  a  different  row.  However,  the  horizontal  dimension  is  not 
broken  into  time  periods.  Instead,  it  is  defined  as  a  time  line  and  the 
actions  taken  by  each  unit  are  described  in  blocks  and  entered  at  the  appro¬ 
priate  point  in  the  time  line  in  the  row  for  the  given  unit.  Blocks  are 
then  connected  by  lines  both  within  and  across  rows  to  show  the  flow  of  in¬ 
formation  and  actions  in  the  scenario.  The  scenario  should  also  be  supported 
by  a  series  of  position  and  movement  diagrams  which  depict  the  actions  at 
each  significant  point  in  the  scenario. 

The  actions  in  each  scenario  are  derived  from  the  general  objectives 
and  tactics  identified  in  the  earlier  part  of  this  phase.  A  given  scenario 
may  use  several  different  kinds  of  presentations.  For  instance,  the  general 
actions  in  the  scenario  may  be  presented  in  a  component  by  time  period  matrix. 
Detailed  actions  within  each  time  period  (columns  of  the  matrix)  may  then  be 
presented  either  as  more  detailed  component  by  time  period  matrices  or  as 
parallel  flowcharts.  Different  levels  of  position  and  movement  diagrams 
might  be  developed  to  accompany  each  of  these  other  presentations.  Computer 
aided  design  (CAD)  can  be  a  very  useful  tool  in  the  identification  and  develop¬ 
ment  of  these  scenarios. 


Step  7.  Identify  episodes  in  each  action  scenario  that  are  significant  to 
the  operation  of  FATDS 

The  seventh  step  of  the  first  phase  is  to  examine  the  scenarios  and 
identify  episodes  that  are  particularly  significant  with  regard  to  the  opera¬ 
tion  of  the  FATDS.  Such  episodes  begin  with  an  event  that  generates  an  input 
into  the  FATDS  and  ends  with  the  outputs  resulting  from  the  input.  The  kinds 
of  events  that  are  most  likely  to  generate  inputs  to  the  field  artillery 
system  and  to  the  FATDS  are  the  emergence  of  field  artillery  targets  that 
pose  an  immediate  or  future  threat  to  elements  of  friendly  forces  (including 
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Figure  3.  Hypothetical  Parallel  Flowchart 


elements  of  the  field  artillery  system  itself)  or  to  the  implementation 
of  battle  plans.  For  this  reason,  a  list  of  the  general  classes  of  field 
artillery  targets  and  a  list  of  the  general  kinds  of  threat  conditions  that 
can  be  generated  against  various  kinds  of  friendly  elements  by  enemy  ele¬ 
ments  could  be  very  useful  in  identifying  specific  episodes  in  each  sce¬ 
nario.  The  description  of  each  episode  should  include  (1)  a  summary  of 
the  events  and  conditions  in  the  scenario  leading  up  to  the  episode,  (2)  the 
general  military  objectives  specified  for  the  scenario,  (3)  the  specific 
field  artillery  objectives  appropriate  for  the  episode,  and  the  (A)  action 
descriptions  and  flow  which  make  up  the  episode.  The  action  descriptions 
and  flow  in  the  episode  are  taken  from  the  scenario  of  which  the  episode 
is  a  part.  The  episodes  are  essentially  "scissored"  out  of  the  scenarios. 
These  episodes  provide  the  basis  for  generating  the  design  requirements  for 
the  FATDS.  They  will  be  analyzed  into  sequences  of  information  processing 
functions  in  the  next  phase. 

Next,  the  list  of  episodes  is  examined  and  judgments  are  made  about  the 
importance  and  frequency  of  each  entry  in  each  list.  Only  the  more  important 
and/or  more  frequent  episodes  need  to  be  retained.  At  this  point,  the  ob¬ 
jective  is  to  reduce  the  list  to  the  most  representative  episodes  that  can 
in  fact  be  analyzed  with  the  resources  available. 

Step  8.  Identify  the  response  demands  imposed  by  the  larger  (artillery) 
system  on  the  FATDS 

The  eighth  and  last  step  in  the  description  of  the  larger  system  is  to 
identify  the  response  demands  imposed  by  the  larger  system  on  the  FATDS. 

The  response  demands  are  derived  from  the  episodes.  Two  sets  of  response 
demands  are  derived  for  each  episode:  (1)  response  demands  for  the  field 
artillery  system  and  (2)  response  demands  for  the  FATDS.  The  latter  are 
derived  from  the  former. 

The  response  demands  are  composed  of  two  parts:  (1)  performance  demands 
and  (2)  condition  demands.  The  performance  demands  specify  how  quickly  and 
how  accurately  either  the  field  artillery  system  or  the  FATDS  must  respond 
in  a  given  episode.  These  general  requirements  can  be  broken  down  to  apply 
to  specific  elements  in  an  episode.  For  instance,  how  much  delay  is  tolerable 
from  the  emergence  of  a  particular  target  until  it  is  detected,  identified, 
and  located  and  entered  into  the  FATDS  communication  loop?  How  accurate 
must  the  information  about  the  target  be?  How  quickly  must  the  field 
artillery  system  respond?  How  accurate  must  the  fire  be?  How  much  time 
is  likely  to  be  available  from  the  time  the  fire  order  is  received  at  the 
fire  unit  until  it  is  carried  out?  How  much  time  is  left  for  the  FATDS 
response?  The  performance  demands  for  each  episode  should  be  attached  to 
the  episode  descriptions.  Once  these  performance  demands  have  been  specified 
for  each  selected  episode,  they  can  be  aggregated  across  episodes  to  form 
general  performance  demands  for  both  the  field  artillery  system  and  the  FATDS. 
These  aggregated  performance  demands  specify  how  well  the  FATDS  must  perform. 
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The  condition  demands  specify  the  environment  characteristics  (humidity, 
temperature,  sensory  characteristics  of  the  battlefield — light  conditions, 
visual  clutter,  noise)  which  bear  on  the  operation  and  maintenance  of  the 
field  artillery  system  and  the  FATDS.  How  humid  will  the  environment  be? 

What  will  the  temperature  be?  What  are  the  sensory  characteristics  of  the 
battlefield?  Light  conditions?  Visual  clutter?  Noise?  How  long  will  the 
field  artillery  system  and  the  FATDS  have  to  sustain  a  given  level  of  activ¬ 
ity  without  degradation  of  their  capabilities?  The  condition  demands  for 
each  episode  should  be  attached  to  the  episode  descriptions.  After  the  con¬ 
dition  demands  have  been  specified  for  each  episode,  then  they  can  be  aggre¬ 
gated  to  form  general  condition  demands  for  both  the  field  artillery  system 
and  the  FATDS . 


PHASE  TWO:  DESCRIBE  THE  INFORMATION  PROCESSING  INTO,  THROUGH,  AND  FROM 
THE  FATDS 

The  outcome  of  this  phase  will  be  a  description  of  the  information 
processing  actions  and  flow  required  to  oe  performed  by  the  combined  human 
and  machine  components  of  the  FATDS. 

This  phase  consists  of  two  steps: 

1.  Describe  the  information  processing  required  of  the  field 
artillery  system  to  perform  effectively  in  each  selected 
episode. 

2.  Describe  the  information  processing  capabilities  required 
by  a  FATDS  to  perform  effectively  in  the  battlefield  during 
the  target  period. 

Each  of  these  steps  is  now  discussed  in  turn. 

Step  1.  Describe  the  information  processing  required  of  the  field  artillery 
system  to  perform  effectively  in  each  selected  episode 

In  the  first  step  each  selected  episode  description  (obtained  in  step 
7  of  phase  one)  is  developed  to  include  the  more  detailed  information 
processing  actions  and  flow  required  for  the  field  artillery  system  to 
perform  effectively  in  that  episode.  Information  can  be: 


1.  Created 

2.  Combined 

3.  Transformed 

4.  Ordered 

5.  Abstracted 

6.  Deleted 

7.  Stored 

8.  Communicated 
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Information  is  created,  for  instance,  when  a  target  is  detected.  Different 
information  is  created  when  the  detected  target  is  categorized  as  to  type 
and  number  (or  size).  Still  different  information  is  created  when  the 
identified  and  categorized  target  is  identified  as  friend  or  foe.  And 
still  different  information  is  created  when  the  target's  location  is  speci¬ 
fied.  In  locating  the  target,  it's  location  may  first  be  noted  with  re¬ 
spect  to  observable  geographical  features.  This  information  is  then  trans¬ 
formed  into  map  coordinates.  Information  is  combined  when  all  of  these 
elements  are  formatted  into  a  target  specification  in  a  fire  request.  In¬ 
formation  is  communicated  when  it  is  sent  from  a  forward  observer  to  the 
fire  control  center.  Information  is  ordered  when  a  fire  order  is  entered 
into  the  waiting  fire  order  list  in  a  particular  priority  position.  Each 
of  these  is  a  separate  information  processing  activity. 

Information  includes  more  than  just  target  and  fire  order  data.  Rules 
governing  a  decision  process  are  information.  A  summary  of  yesterday’s  ac¬ 
tions  is  information.  Plans  and  expectations  are  also  information.  The 
outcomes  of  decision  processes  are  information.  Each  of  these  has  to  be 
created  or  transformed  so  as  to  be  available  for  use. 

The  information  processing  actions  performed  in  each  episode  need  to 
be  specified  in  detail.  If  a  target  is  detected,  specify  what  kind  of  target 
and  in  what  kind  of  sensory  or  energy  environment.  For  instance,  information 
processing  actions  should  be  specified  with  the  following  kinds  of  detail: 
"detect  single  tank  at  one  kilometer  distance  at  night,"  "categorize  single 
tank  at  one  kilometer  at  night,"  "identify  single  tank  as  friend  or  foe  at 
1  1/2  kilometers  in  wooded  area  on  overcast  day,"  "select  type  XYZ  guns  and 
XYZ  round  to  fire  against  column  of  enemy  tanks  XX  kilometers  away,"  "trans¬ 
mit  request  for  fire  on  column  of  tanks  located  at  coordinates  XX,  YY," 
and  so  on. 

Each  information  processing  action  should  be  identified  in  terms  of 
the  major  component  of  the  field  artillery  system  that  is  to  perform  it. 

All  elements  of  a  major  component  must  be  located  together  geographically. 

For  instance,  major  components  include  the  forward  observers,  the  battalion 
fire  control  center,  and  the  division  artillery  tactical  operations  center. 
The  elements  that  make  up  each  of  these  components  are  physically  co-located. 
The  component  that  is  responsible  for  performing  each  information  processing 
action  can  be  specified  by  developing  a  parallel  flowchart  (see  Figure  3) 
for  describing  the  information  flow  for  each  episode.  Each  component  is 
assigned  to  a  row  in  the  flowchart.  Information  processing  actions  are 
then  entered  in  order  in  the  appropriate  row  of  the  flowchart  and  connected 
by  arrows  to  specify  the  flow  of  information  from  one  entry  to  another  both 
in  the  same  row  and  in  different  rows.  Arrows  which  go  from  one  row  to 
another  must  always  originate  from  a  communication  action. 
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There  are  some  actions  that  may  be  difficult  to  identify  in  developing 
the  parallel  flowcharts.  The  need  to  store,  delete,  or  abstract  informa¬ 
tion  may  not  always  be  apparent  from  the  context  of  a  single  episode.  One 
way  of  improving  our  ability  to  detect  the  need  for  these  kinds  of  actions 
is  to  review  the  context  (or  past  action)  summaries  in  the  original  episode 
descriptions.  These  summaries  should  also  provide  indications  as  to  the 
rate  at  which  inputs  are  being  made  into  the  field  artillery  system  and 
the  FATDS  during  various  kinds  of  military  situations.  Whenever  a  decision 
activity  is  entered  into  the  flowchart,  we  should  also  check  whether  or  not 
it  requires  application  of  a  set  of  rules  or  principles  and  whether  it  re¬ 
quires  a  prior  review  of  other  information  such  as  a  summary  of  past  actions. 
Developing  plans  and  expectations  will  also  require  similar  collateral  ac¬ 
tivities. 

The  effort  required  to  develop  the  information  processing  flowcharts 
might  be  reduced  by  sorting  the  episode  descriptions  into  piles  on  the 
basis  of  the  kinds  of  field  artillery  actions  required  to  deal  effectively 
with  each  one.  A  single  analyst  or  team  of  analysts  may  then  be  assigned 
to  each  pile  of  similar  episodes.  In  this  way  the  analysts  can  develop  im¬ 
plicit  patterns  for  analyzing  each  pile  of  similar  episodes.  In  fact,  they 
may  use  the  early  flowcharts  as  models  for  the  later  ones.  Developing  the 
flowcharts  on  small  computers  using  word  processing  software  and  appropriate 
graphics  software  would  also  greatly  speed  up  their  preparation,  review,  and 
revision.  It  would  also  make  it  easy  for  the  analysts  to  insert  pieces  of 
previously  prepared  flowcharts  into  new  flowcharts  where  appropriate.  This 
is  another  way  in  which  computer  aided  design  could  facilitate  this  kind  of 
effort. 


Step  2.  Describe  the  Information  processing  capabilities  required  by  a 
FATDS  to  perform  effectively  in  the  battlefield  during  the  target  period 

In  the  second  step  all  of  the  flowcharts  developed  for  the  separate 
episodes  are  combined  into  as  few  flowcharts  as  are  required  to  describe 
the  information  processing  activities  and  flow  in  the  field  artillery  system. 
As  the  single  episode  flowcharts  are  combined,  they  need  to  be  examined  for 
additional  storing,  deleting,  and  abstracting  activities.  Development  of 
the  combined  flowcharts  is  principally  a  matter  of  combining  and  editing 
the  single  episode  flowcharts.  First,  the  single  episode  flowcharts  can 
be  sorted  into  piles  on  the  basis  of  their  overall  similarities.  Next, 
common  routines  consisting  of  similar  or  identical  sequences  of  steps  in 
the  various  flowcharts  are  identified  and  edited.  Third,  unique  routines 
are  identified.  And,  finally,  the  common  and  the  unique  routines  are  com¬ 
bined  into  several  comprehensive  FATDS  flowcharts.  If  the  single  episode 
flowcharts  were  prepared  on  a  computer  and  stored  on  disk,  then  the  develop¬ 
ment  of  the  combined  flowcharts  should  proceed  quite  rapidly. 
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The  comprehensive  FATDS  flowcharts  specify  the  information  processing 
activities  and  flow  required  in  a  field  artillery  system  to  perform  effec¬ 
tively  in  the  more  significant  environments/situations  anticipated  for  the 
target  period.  These  flowcharts  will  provide  one  of  two  major  inputs  to 
the  first  phase  of  the  design  and  decision  process  in  which  the  information 
processing  activities  will  be  allocated  to  either  human  or  machine  components 
of  the  various  alternative  FATDS  concepts.  The  other  major  input  will  be 
prepared  in  the  third  phase  of  the  front-end  analysis,  which  follows. 


PHASE  THREE:  ANALYZE  THE  HUMAN  MONITORING  AND  POSSIBLE  OVERRIDE  ROLE 
IN  THE  FATDS 

The  outcome  of  this  phase  will  be  a  description  of  the  information 
processing  activities  required  to  monitor  the  FATDS  operation  and,  if 
necessary,  to  override  a  FATDS  decision.  This  phase  consists  of  three  steps: 

1.  Review  the  general  cognitive  model  for  commanders/monitors  of 
remote  systems.  Monitoring  a  remote  system  requires  essentially 
the  same  though  processes  as  are  required  to  operate  the  system. 

The  general  model  provides  guidance  for  identifying  these  thought 
processes . 

2.  Identify  the  conditions  and  situations  of  the  field  artillery 
system  and  its  environment  and  the  information  bases  that  need 
to  be  monitored. 

3.  Describe  the  information  processing  activities  required  to 
monitor  and,  if  necessary,  to  override  the  information  processing 
activities  of  the  FATDS. 


Step  1.  Review  the  general  cognitive  model  for  commanders/monitors  of 
remote  systems 

The  first  step  consists  of  reviewing  the  general  cognitive  model  for 
commanders /monitors  of  remote  systems.  A  remote  system  is  one  that  is 
linked  to  its  control  center  through  human/machine  interfaces  that  present 
only  symbolic  or  abstracted  representations  of  the  state  of  the  system  and 
its  environment  to  the  human  personnel  who  control  it  and  that  accepts  con¬ 
trol  from  these  personnel  only  through  symbolic  or  abstracted  control  actions. 
Commanders,  operators,  and  monitors  of  remote  systems  are  linked  to  the 
systems  they  control  only  through  displays  and  controls  in  some  remote 
control  center. 
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An  overview  of  the  general  model.  Monitoring  a  system  activity  with 
a  view  towards  overriding  the  decisions  made  in  that  system  essentially 
requires  that  the  monitor  perform  the  same  information  processing  activities 
in  parallel  with  the  system  as  performed  by  the  system  itself.  If  the  moni¬ 
tor  makes  a  decision  that  does  not  match  the  corresponding  decision  made 
by  the  system,  then  the  monitor  has  to  consider  whether  or  not  to  override 
the  system. 

Figure  4  is  a  diagram  which  identifies  the  general  activities  required 
to  command  or  monitor  a  remote  system  and  shows  the  flow  of  information 
among  the  activities.  The  remote  system,  represented  at  the  left  side  of 
the  diagram,  is  separated  from  the  commander/monitor  by  the  human/machine 
interface.  The  interface  consists  of  displays  and  controls.  Information 
about  the  states  of  the  field  artillery  system  and  its  environment  and  about 
information  bases  within  the  system  is  made  available  to  the  commander /monitor 
by  means  of  the  displays.  The  commander/ monitor  implements  his  decisions 
through  the  controls.  The  remaining  entries  in  the  diagram  represent  the 
activities  performed  by  the  commander/monitor  of  the  remote  system.  Those 
activities  outside  the  dotted  lines  are  required  of  both  the  commander  of 
the  system  and  the  monitor.  Those  activities  inside  the  dotted  lines  are 
added  as  a  result  of  the  monitoring  and  potential  override  requirement. 

The  general  model  provides  guidance  for  identifying  the  activities  required 
of  a  system  commander/monitor. 

The  upper  string  of  activities  represents  the  inputs  to  the  commander/ 
monitor.  The  lower  string  of  activities  represent  the  outputs  from  the 
commander/monitor.  The  intermediate  activities  represent  the  commander/ 
monitor's  decision  processing.  The  model  breaks  the  intermediate  activities 
into  three  major  functions:  (1)  The  construction  and  maintenance  of  a 
representation  of  the  current  and  emerging  state  of  the  remote  system 
based  in  part  upon  its  past  states,  (2)  a  decision  process  for  identifying 
and  selecting  appropriate  courses  of  action,  and  (3)  a  decision  process  for 
determining  whether  or  not  to  override  the  system.  The  first  function 
appears  as  a  large  circular  loop  of  activities  in  the  upper  right  portion 
of  the  diagram.  The  second  appears  as  a  diamond  shaped  array  in  the  lower 
right  portion  of  the  diagram.  And  the  third  appears  as  a  string  of  activities 
at  the  bottom  of  the  diagram  inside  the  box  bounded  by  a  dotted  line. 

The  input  branch  of  the  model  consists  of  three  activities:  (1)  Dis¬ 
criminate  the  display  elements,  (2)  identify  the  conditions  of  the  remote 
system  and  its  environment  on  the  basis  of  the  display  elements,  and 
(3)  identify  the  present  situations  of  the  remote  system  and  its  environ¬ 
ment  based  on  the  present  conditions,  the  recent  history  of  the  system, 
and  expectations  about  future  situations.  "Conditions"  in  this  usage  are 
discrete  characteristics  that  make  up  more  encompassing  situations.  For 
instance,  the  detection  of  movement  in  an  enemy  armor  unit  may  be  a  condi¬ 
tion  in  a  more  general  situation  consisting  of  the  initiation  of  an  assault 
by  the  enemy.  The  second  and  third  activities  in  this  branch  successively 
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FIGURE  1.  GENERAL  COGNITIVE  ACT  MODEL  FOR  OFERATORS/CCmWERS  OF  REMOTE  SYSTEMS. 


aggregate  the  display  information  at  a  higher  level  of  abstraction.  For 
instance,  the  detection  of  movement  in  an  enemy  armor  unit  may  signal  a 
local  assault.  Added  to  knowledge  about  an  enemy  build-up  of  supplies  and 
the  onset  of  bad  weather,  the  inference  might  be  drawn  that  the  enemy  is 
initiating  a  final  assault  to  establish  a  more  favorable  position  before 
a  winter  storm  sets  in.  This  inference  is  a  higher  level  abstraction  of 
the  actual  battlefield  conditions.  These  successive  abstractions  are 
basically  pattern  recognition  activities.  (See  Whitmore,  Richards,  and 
McIntyre,  1982,  for  a  description  of  the  recognize/classify  Generic  Activity 
Model.)  '  '  ~  ' 

The  output  branch  of  the  model  also  consists  of  three  activities: 

(1)  Identify  response  actions,  (2)  discriminate  control  elements,  and 

(3)  implement  response  actions.  The  input  to  this  branch  is  the  decision 
to  override  the  FATDS  response  alternative. 

The  third  activity  in  the  input  branch  of  the  model  (identify  remote 
situations)  is  also  the  first  activity  in  the  "state  of  the  system"  loop. 

This  identification  of  the  remote  situation  is  used  in  the  next  activity 
(construct  remote  situation  development)  to  initiate  or  update  a  repre¬ 
sentation  of  the  recent  history  of  the  remote  system  and  its  environment. 

The  recent  history  information  is  then  used  in  three  subsequent  activities. 
First,  it  is  used  to  identify  remote  conditions  that  exist  over  time. 

Second,  it  can  be  used  to  identify  remote  situations  that  exist  over  time. 
And,  third,  it  is  the  basis  for  applying  remote  systems  theory:  (1)  for 
developing  expectations  about  emerging  events  in  the  remote  system  and 

(2)  for  identifying  and  selecting  response  alternatives  for  dealing  with 
problem  situations  in  the  remote  system.  Remote  system  theory  for  a  FATDS 
consists  of  the  principles  of  tactics  used  by  friendly  and  enemy  forces. 

These  principles  (or  rules)  are  the  statements  applied  by  a  commander/monitor 
(1)  to  interpret  the  conditions  and  situations  occurring  in  the  remote 
system  and  its  environments,  (2)  to  develop  expectations  about  what  is 
likely  to  happen  in  the  near  future,  and  (3)  to  formulate  action  alternatives 
and  select  among  them.  They  may  well  include  more  than  just  formally  recog¬ 
nized  principles  of  tactics. 

The  array  of  decision  activities  receive  inputs  from  the  remote  systems 
theory  (that  is,  the  commander's  application  of  principles  of  tactics  from 
memory)  and  from  expectations  regarding  developments  in  the  remote  systems 
(that  is,  the  battlefield,  enemy  forces,  and  friendly  forces).  These  two 
sources  of  information  lead  to  (1)  the  identification  of  response  alterna¬ 
tives,  (2)  the  identification  of  constraints  on  the  selection  of  a  response 
alternative,  and  (3)  the  identification  of  demands  (goals)  on  the  selection 
of  a  response.  These  three  activities,  in  turn,  feed  their  information 
into  the  actual  selection  of  a  response  alternative. 
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The  string  of  monitoring-specific  activities  receives  an  input  from 
the  displays  regarding  the  response  alternative  selected  by  the  FATDS  and 
an  input  from  the  monitor's  previous  processing  (i.e.,  thinking)  regarding 
his  own  response  alternative  selection.  These  two  selections  are  compared. 

If  they  match,  no  intervention  is  required.  If  they  do  not  match ,  then 
the  monitor  has  to  decide  whether  or  not  to  override  the  FATDS  selection. 

This  decision  is  usually  based  on  a  projection  made  by  the  monitor  regarding, 
the  likely  difference  in  consequences  between  his  selection  and  the  FATDS 
selection.  If  the  differences  in  projected  consequences  are  significant 
and  favor  his  alternative,  then  he  identifies  the  response  actions  he  needs 
to  override  the  FATDS  and  proceeds  into  the  output  branch  of  the  model. 

One  final  activity  in  the  model  remains  to  be  explained:  Identi fv 
action  criterion  situation  (near  the  center  of  the  diagram).  The  action 
criterion  situation  may  be  viewed  as  a  triggering  situation  for  initiating 
a  selected  response  alternative.  It  is  defined  from  the  identification  of 
the  response  actions  and  from  expectations  concerning  developments  in  the 
remote  situation.  When  the  current  remote  situation  matches  the  criterion 
situation,  the  response  actions  for  the  selected  response  alternative  are 
implemented.  The  action  criterion  situation  represents  a  "Don't  shoot  until 
you  see  the  whites  of  their  eyes"  condition. 

Variations  on  the  general  model.  Three  principal  kinds  of  variations 
can  be  introduced  into  the  general  model.  First,  certain  activities  might 
be  omitted  from  the  model.  For  instance,  the  identification  of  an  action 
criterion  situation  may  not  be  appropriate  in  some  instances.  Or  it  may 
not  be  necessary  to  consider  the  development  of  remote  situations  in  the 
recent  past.  In  an  extreme  instance,  the  identification  of  a  remote  condi¬ 
tion  may  directly  trigger  the  selection  of  a  response  alternative,  completely 
omitting  the  "state  of  the  system"  loop  and  the  decision  process  array.  In 
this  instance,  indications  of  remote  conditions  serve  directly  as  response 
signals . 

The  second  kind  of  variation  in  the  model  deals  with  the  certainty  with 
which  information  can  be  processed.  Aggregation  on  the  input  branch,  for 
instance,  can  be  deterministic  or  probabilistic.  The  identification  of  a 
remote  situation  might  be  based  on  the  presence  of  a  fixed  set  of  conditions 
or  it  might  be  based  on  a  variable  set  of  conditions,  with  each  one  con¬ 
tributing  a  different  amount  to  the  identification;  that  is,  it  is  a  matter 
of  uncertain  judgment.  The  same  kind  of  variation  can  also  apply  in  the 
"state  of  the  system"  loop,  the  decision  process  array,  the  intervention 
string,  and  the  output  branch.  Furthermore,  some  activities  in  the  model 
might  process  information  in  deterministic  ways  and  others  might  use 
probabilistic  ways. 

The  third  kind  of  variation  in  the  model  deals  with  the  level  of  ab¬ 
straction  used  in  different  activities  in  the  model.  It  seems  likely  that 
the  more  complex  the  remote  system  the  higher  the  level  of  abstraction  needed 
for  monitoring  and  controlling  it.  In  regard  to  this  point,  Rasmussen  and 
Lind  (1981)  note: 
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Since  the  human  capacity  tor  analysis  and  decison  in  a 
non-routine  situation  is  notoriously  limited  to  consideration 
of  a  very  limited  number  of  items  of  information,  the  only 
way  to  cope  with  the  high  number  of  information  sources  and 
devices  of  elementary  actions.  .  . is  to  structure  the  situation 
and  to  transfer  the  problem  to  a  representation  at  a  level 
with  less  resolution.  The  total  data  processing  task  then  is: 

To  structure  the  information  at  a  higher  level  of  representa¬ 
tion  of  the  states  of  the  system;  to  make  a  choice  of  intention 
at  that  level;  and  then  to  plan  the  sequence  of  detailed  acts 
which  will  suit  the  higher  level  intention.  .  . 

But  even  a  very  complex  system  may  involve  a  few  very  simple  activities 
that  can  be  processed  at  a  low  level  of  abstraction.  It  is  also  possible 
that  different  complex  transactions  may  require  different  levels  of  ab- 
stration  for  most  effective  processing.  With  regard  to  the  various  levels 
of  abstraction  that  may  be  involved  in  an  activity,  Rasmussen  and  Lind 
further  note: 

When  moving  from  one  level  of  abstraction  to  the  next  higher 
level,  the  change  in  system  properties  represented  is  not 
merely  removal  of  details  of  information  on  the  physical  or 
material  properties.  More  fundamentally,  information  is  added 
on  higher  level  principles  governing  the  co-function  of  the 
various  functions  or  elements  at  the  lower  level.  In  human- 
made  systems,  these  higher  level  principles  are  naturally 
derived  from  the  purpose  of  the  system;  i.e.,  from  the  reasons 
for  the  configurations  at  the  level  considered. 

For  instance,  a  set  of  tactical  principles  may  apply  quite  well  to  a  high 
level  abstraction  of  a  situation,  but  make  no  sense  at  all  when  applied  to 
a  more  detailed  representation  of  the  situation.  The  more  detailed  repre¬ 
sentation  would  have  to  be  transformed  into  more  abstract  patterns  or 
relationships  before  the  principles  would  make  sense. 

Application  of  the  general  model.  The  general  model  can  be  used  to 
guide  the  development  of  a  description  of  the  optimum  information  processing 
to  be  used  by  commanders /monitors  of  FATDS  conceptualizations.  There  is 
nothing  magic  about  the  model.  It  serves  principally  to  call  the  analyst's 
attention  to  a  likely  sequence  of  activities  which  may  occur  in  the  command¬ 
ing  or  monitoring  of  a  real  system.  The  model  was  developed  for  this  purpose 
by  specialists  who  are  trained  and  experienced  in  the  analysis  of  human  per¬ 
formances.  It  reflects  some  current  points  of  view  from  theoretical 
cognitive/behavioral  science,  but  it  has  not  been  subjected  to  controlled 
experimentation. 
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Step  2.  Identify  the  conditions  and  situations  of  the  field  artillery 
system  and  Its  environment  and  the  Information  bases  that  need  to  be  monitored 


Now  that  the  commanding/monitoring  role  for  a  remote  system  has  been 
described,  it  is  necessary  to  determine  what  is  to  be  monitored.  What  are 
the  critical  situations  that  can  occur  in  the  remote  system  to  which  the 
system  should  respond?  What  kinds  of  situations  or  conditions  that  precede 
the  occurrence  of  a  critical  situation;  that  is,  what  are  the  possible  sig¬ 
nals  that  a  critical  situation  may  be  developing?  Critical  situations  may 
exist  in  the  battlefield  or  in  the  firing  units  or  with  regard  to  other 
friendly  forces  or  with  regard  to  re-supply  conditions.  Critical  situations 
can  occur  in  any  part  of  the  field  artillery  system  or  its  environment.  The 
situation  identification  analysis  done  in  the  first  phase  of  the  front-end 
analysis  might  well  be  extended  at  this  point  to  include  other  parts  of  the 
system  and  its  environment.  It  can  then  be  used  as  a  basis  for  identifying 
potentially  critical  situations  and  conditions  that  either  ought  to  elicit 
responses  from  the  system  or  that  ought  to  help  to  determine  what  response 
is  most  appropriate. 


Step  3.  Describe  the  information  processing  activities  required  to  monitor 
and,  if  necessary,  override  the  information  processing  activities  of  the  FATDS 

This  step  proceeds  in  two  substeps.  In  the  first  substep,  describe 
the  information  processing  required  to  monitor  each  situation  or  condition 
identified  in  the  second  step  using  the  general  cognitive  model  reviewed  in 
the  first  step  to  help  identify  potential  information  processing  activities. 
The  overall  descriptions  of  the  activity  sequences  should  probably  take  the 
form  of  simple  activity  diagrams  or  flowcharts.  The  entries  describing  each 
activity  in  each  diagram  or  flowchart  should  be  very  specific  as  in  the  first 
step  of  the  second  phase  of  the  front-end  analysis.  It  is  necessary  to  be 
specific  about  what  is  identified,  what  tactical  principles  are  applied,  and 
so  on.  In  the  second  substep,  the  descriptions  developed  in  the  first  substep 
are  combined  into  as  few  descriptions  as  possible. 

The  combined  information  processing  descriptions  developed  in  this  phase 
and  in  the  preceding  phase  provide  the  input  to  the  first  phase  in  the  design 
and  decision  process  which  follows.  In  the  first  phase  of  the  design  and 
decision  process,  the  information  processing  activities  identified  in  these 
two  phases  are  allocated  either  to  human  or  machine  components  of  the  various 
FATDS  alternative  concepts. 
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STACK  TWO:  DKS1GN  AND  DECISION  PROCESS 


1 


The  objective  of  Stage  2  is  to  develop  a  concept  for  the  C3  system 
(FATDS)  in  terms  of  hardware,  software,  and  behavioral  technologies  that 
meets  the  system  response  demands  identified  in  the  first  stage.  Stage  2 
is  carried  out  in  two  phases  described  as  follows. 

PHASE  ONE:  ALLOCATE  INFORMATION  PROCESSING  ACTIVITIES  TO  HUMAN  OR  MACHINE 

Phase  1  is  concerned  with  the  development  of  several  alternative  de¬ 
sign  concep ts  for  a  FATDS  in  which  information  processing  activities  are 
allocated  to  humans  or  to  various  machine  technologies  in  different  ways. 
Each  design  concept  is  then  evaluated  and  the  best  of  the  concepts  is  re¬ 
vised  to  improve  it,  if  possible.  The  phase  consists  of  nine  steps: 

1.  Develop  the  machine  technology  focus  for  each  design  concept. 

2.  Develop  the  human/machine  allocation  rationales  for  each  design 
concep  t . 

3.  Allocate  information  processing  functions  in  each  design  concept 
to  humans  or  machines. 

4.  Determine  the  importance  of  each  information  processing  activity 
to  the  attainment  of  field  artillery  objectives  (missions). 

5.  Review  the  design  impact  factors  (DIFs)  and  weight  them  according 
to  their  importance. 

6.  Obtain  ratings  for  each  information  processing  (IP)  activity  in 
each  design  concept  on  each  DIF. 

7.  Obtain  figures  of  merit  (FOMs)  on  each  DIF  for  each  design  concept. 

8.  Obtain  aggregate  FOM  for  each  design  concept. 

9.  Review  the  results  of  the  two  previous  steps  in  an  attempt  to 
improve  the  highest  rated  design  concept. 

The  outcome  of  phase  2  is  a  specification  of  the  best  human/machine  function 
allocation  for  each  information  processing  activity  and  the  selection  of  a 
preferred  machine  technology  for  accomplishing  each  machine-allocated  ac¬ 
tivity.  Each  design  concept  is  evaluated  in  terms  of  its  impact  on  factors 
such  as  personnel,  training,  system  development  (developmental  time. 


technological  risk,  reliability,  availability,  maintainability, 
f lexibility/adaptability ) ,  and  performance.  The  valuing  process  is  a 
variation  of  multiple  attribute  utility  technology  (MAUT).  The  suggested 
rating  procedures  represent  an  amalgam  of  various  methods  assembled  for 
the  purpose  of  conducting  trade-off  analyses.  An  interested  reader  may 
consult  Hawley,  Brett,  and  Chapman  (1982)  for  more  information  on  the 
rating  procedures  described  herein. 


Step  1.  Develop  the  machine  tec) mo logy  focus  for  each  design  concept 

For  the  past  several  decades,  information  processing  machine  tech¬ 
nologies  have  been  in  a  state  of  rapid  development.  Consequently,  it  is 
necessary  to  consider  not  only  those  technologies  currently  available,  but 
also  emerging  technologies  that  may  well  be  available  at  the  appropriate 
point  in  the  development  of  the  PATHS.  It  is  also  necessary  to  consider 
the  possibility  that  existing  technologies  may  not  be  capable  of  producing 
a  FATDS  design  that  can  meet  the  system  response  demands  for  our  target 
period.  If  that  should  prove  to  be  the  case,  then  we  need  to  be  able  to 
identify  precisely  where  the  shortfalls  lie  and  take  steps  to  enhance  the 
development  of  the  appropriate  technologies. 

Alternative  design  concepts  need  to  be  developed  that  address  at  least 
three  different  levels  of  machine  technology. 

1.  Existing  technologies.  The  design  concept  at  this  level  will 
draw  only  from  those  information  processing  machine  technologies 
that  are  fully  developed  and  on  the  commercial  market  at  this  time. 

2.  State-of-the-art  technologies.  The  design  concept  at  this 
level  will  draw  not  only  from  existing  technologies  but  also 
from  those  technologies  whose  potential  has  been  proven  in 
research  applications  and  perhaps  in  some  prototype  applica¬ 
tions,  but  they  are  not  yet  commercially  available. 

3.  Foreseeable  technologies.  The  design  concept  at  this  level 
will  draw  not  only  from  existing  and  state-of-the-art 
technologies,  but  also  from  technologies  which  are  theoretically 
feasible  but  have  not  been  tested  in  any  applications. 

Using  these  definitions  as  a  guide,  each  information  processing  activity 
in  the  aggregated  system  descriptions  is  examined  and  potential  information 
processing  machine  technologies  at  each  level  for  performing  each  activity 
are  identified,  if  possible.  There  may  well  be  several  technologies  at  the 
same  level  that  apply  to  a  single  information  processing  activity.  At  this 
point,  list  them  all.  The  persons  who  make  these  judgments  should  be 
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knowledgeable  concerning  the  various  information  processing  technologies. 

Some  of  these  experts  might  be  military  personnel,  some  might  be  Department 
of  Defense  (DoD)  civilians,  some  might  be  scientists  and  engineers  with 
manufacturing  firms,  and  some  might  be  scientists  and  engineers  in  research 
institutions  or  universities. 

If  the  persons  who  are  to  make  the  judgments  can  be  assembled  in  small 
groups  in  one  place,  it  would  be  desirable  to  use  a  group  process  (see 
Delbeq,  Van  de  Ven,  &  Gustafson,  1975)  to  facilitate  face-to-face  interac¬ 
tion  among  the  individuals  in  arriving  at  their  judgments.  Group  processes 
are  designed  to  stimulate  idea-getting.  If  the  individuals  cannot  be  assembled 
at  one  place  at  one  time,  then  a  Delphi  approach  would  be  useful.  A  Delphi 
approach  consists  of  obtaining  successive  rounds  of  judgments  from  experts 
in  writing  with  summarization  of  each  round  and  feedback  of  the  summariza¬ 
tion  to  the  individuals  before  the  next  round.  Delphi  can  be  conducted  by 
mail,  but  it  takes  a  long  time  to  apply. 


Step  2.  Develop  the  human/machine  alloc a t i on  rat i on ales  _for_  each  design 
concept 

Before  information  processing  activities  can  be  allocated  either  to 
humans  or  a  machine,  it  is  necessary  to  decide  what  kinds  of  performs:  j 
characteristics  are  important  in  performing  each  information  processing  ac¬ 
tivity.  In  some  instances,  speed  of  response  may  be  important,  in  other 
instances  total  throughput  per  unit  time  may  be  important,  in  other  instances 
amount  of  information  stored  may  be  important  or  ability  to  abstract  informa¬ 
tion  may  be  important.  Several  performance  characteristics  might  be  im¬ 
portant  for  any  given  information  processing  activity. 

Performance  characteristics  should  be  specified  for  every  single  in¬ 
formation  processing  activity  in  the  aggregated  system  descriptions,  regard¬ 
less  of  whether  or  not  it  is  to  be  allocated  to  a  machine.  These  character¬ 
istics  should  be  specified  by  those  available  personnel  who  have  had  the 
most  intensive  experience  in  commanding  and  operating  existing  FATDS  in  the 
most  combat-like  situations  possible.  However,  they  will  need  more  than 
just  their  experience  as  a  basis  for  specifying  performance  characteristics. 
They  should  also  be  provided  with  a  summary  of  the  system  response  demands 
and  a  summary  of  the  selected  episode  descriptions  from  the  front-end 
analysis  (Stage  1)  and  time  in  which  to  review  them  thoroughly.  Again, 
if  possible,  decisions  should  be  made  using  a  group  process.  If  it  is  not 
possible,  then  use  the  Delphi  technique. 
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Step  3.  Allocate  Information  processing  functions  In  each  design  concept 
to  human  or  machine 


At  this  point,  alternative  information  processing  technologies  will 
have  been  specified  at  each  design  level  for  many  if  not  all  of  the  informa¬ 
tion  processing  activities.  Furthermore,  performance  characteristics  will 
have  been  identified  for  every  single  information  processing  activity.  If 
no  machine  technology  is  specified  for  an  information  processing  activity 
at  a  given  design  level,  the  allocation  automatically  defaults  to  "human". 

A  judgment  has  to  be  made  about  each  information  processing  activity 
at  each  design  level  for  which  one  or  more  machine  technologies  have  been 
specified.  Humans  are  automatically  added  to  the  list  of  alternative  tech¬ 
nologies  for  each  activity  at  each  level.  In  a  sense,  humans  are  being 
treated  as  one  more  technological  alternative  for  every  activity  at  each 
design  level.  The  list  of  alternatives  for  each  activity  at  each  design 
level  is  examined  and  compared  to  the  performance  characteristics  for  the 
activity.  The  alternative  that  offers  the  most  performance  potential  is 
selected  for  that  activity  at  that  design  level.  If  two  or  more  alterna¬ 
tives  are  judged  to  be  equally  promising,  then  all  of  them  should  be  selected. 
In  this  way,  alternative  design  concepts  can  be  developed  at  each  level. 

Sometimes  it  may  not  be  possible  for  one  technology  by  itself  to  per¬ 
form  a  given  information  processing  activity.  The  assignment  of  a  technology 
to  an  activity  in  such  a  case  is  ambiguous.  If  one  of  those  technologies 
is  "human,"  it  has  been  common  practice  to  allow  the  designation  of  "shared" 
to  that  activity;  that  is,  the  performance  of  the  activity  is  judged  to  be 
shared  by  human  and  one  or  more  equipment  technologies.  In  the  approach  out¬ 
lined  in  this  report,  it  is  recommended  that  if  an  activity  cannot  be  assigned 
unequivocably  to  one  technology,  then  the  activity  should  be  divided  into 
smaller  component  activities  until  a  level  of  activity  is  reached  that  can 
be  assigned  unequivocably  to  single  technologies.  This  procedure  should  be 
particularly  stressed  for  ambiguous  assignments  that  involve  "human"  as 
one  of  the  technologies. 

The  judgments  for  allocating  information  processing  activities  at  each 
level  to  the  most  appropriate  technologies  should  be  made  by  a  mix  of  people 
who  possess  expertise  in  each  of  the  relevant  technologies.  Since  humans 
are  always  one  of  the  alternatives  to  be  considered,  at  least  one  fourth  of 
the  mix  should  represent  expertise  in  human  factors.  Again,  small  groups 
should  be  formed  with  the  appropriate  mix  of  experts  and  a  group  process 
should  be  used  to  guide  the  interactions  among  the  members  of  each  group  in 
arriving  at  their  judgments.  And,  again,  the  members  of  the  groups  should 
be  provided  with  summaries  of  the  results  of  the  front-end  analysis  and  with 
the  aggregate  flowcharts.  It  is  critical  in  this  pr cess  that  the  best  avail¬ 
able  experts  in  each  technology  participate  in  the  da. vocation  judgments. 

A  non-expert  or  "weak  expert  in  one  of  the  technologies  can  degrade  the  re¬ 
sults,  especially  if  that  person  is  the  sole  representative  for  a  given 
stakeholder. 
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The  results  of  the  allocation  judgments  should  be  presented  in  the 
form  of  parallel  flowcharts  with  a  different  row  assigned  to  each  technology, 
including  humans.  Flowchart  lines  going  from  an  entry  in  the  row  assigned 
to  humans  to  an  entry  in  one  of  the  other  rows  represents  a  human-to-machine 
transaction.  Flowchart  lines  going  from  an  entry  in  one  of  the  machine 
technology  rows  to  an  entry  in  the  row  assigned  to  humans  represent 
machine- to-human  transactions.  It  is  these  human-to-macine  and  machine- 
to-human  transactions  that  will  be  considered  in  the  second  phase  of  the 
design  and  decision  process. 

The  remaining  steps  in  this  phase  are  concerned  with  deciding  which 
design  alternative  or  alternatives  to  pursue. 


Step  4.  Determine  the  importance  of  each  information  processing  activity 
to  the  attainment  of  field  artillery  objectives  (missions) 

Some  information  processing  activities  are  more  important  for  accom¬ 
plishing  the  objectives  of  the  field  artillery  system  than  are  others.  The 
mistake  of  investing  a  substantial  portion  of  the  project’s  resources  into 
developing  the  means  for  performing  relatively  unimportant  activities  should 
be  avoided.  Nor  should  the  project  skimp  needlessly  on  the  relatively  im¬ 
portant  activities.  Consequently,  it  is  necessary  to  assign  each  informa¬ 
tion  processing  activity  a  value  that  reflects  its  criticality  for  accomplish¬ 
ing  field  artillery  missions. 

The  criticality  judgments  for  the  activities  should  be  made  by  those 
available  personnel  who  have  had  the  most  extensive  experience  in  commanding 
and  operating  existing  FATDS  in  the  most  combat-like  situations  possible. 
However,  they  will  need  more  than  just  their  experience  as  a  basis  for 
judging  criticality.  They  should  also  be  provided  with  a  summary  of  the 
system  response  demands  and  a  summary  of  the  selected  episode  descriptions 
from  the  front-end  analysis  and  time  in  which  to  review  them  thoroughly. 

Again,  if  possible,  use  a  group  process.  If  it  is  not  possible,  then  use 
the  Delphi  technique. 

The  criticality  judgments  can  be  made  any  time  after  the  front-end 
analysis  has  been  completed.  Since  these  judgments  are  obtained  by  the 
same  general  process,  from  the  same  general  population  of  experts,  and  re¬ 
quire  that  the  experts  have  the  same  summary  of  the  front-end  analysis  as 
required  for  specifying  the  performance  characteristics  for  each  informa¬ 
tion  processing  activity  in  the  second  step  of  this  phase,  then  it  seems 
reasonable  to  obtain  the  criticality  judgments  at  the  same  time,  in  the  same 
way,  and  from  the  same  sources  as  the  performance  characteristics  are  obtained. 

There  are  two  different  procedures  that  can  be  used  for  obtaining  the 
criticality  judgments.  The  first  procedure  is  used  if  there  are  ten  or 
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fewer  information  processing  activities — an  unlikely  possibility.  The 
second  procedure  is  used  if  there  are  more  than  ten  information  processing 
activities.  Again,  the  rating  technique  is  adapted  from  procedures  de¬ 
scribed  in  Hawley,  et^  al^  (1982). 

Procedure  for  ten  or  fewer  activities: 

1.  List  the  information  processing  activities  in  descending  order 
of  importance. 

2.  Assign  the  least  important  activity  a  rating  of  10. 

3.  Consider  the  next-least-important  activity.  How  much  more 
important  is  it  than  the  least  important?  Assign  it  a  number 
that  reflects  that  ratio.  For  example,  if  the  second-least- 
important  activity  is  judged  to  be  four  times  as  important  as 
the  least-important,  it  is  assigned  a  score  of  40.  Continue  up 
through  the  list  of  activities  and  assign  each  one  a  value  in 

the  same  way.  Check  each  set  of  ratios  as  new  judgments  are  made. 

4.  Review  the  ratings  to  insure  that  they  reflect  the  relative 
importance  of  each  of  the  activities.  Are  the  ratios  of 
distances  between  activities  correct?  Make  any  necessary 
adjustments  to  the  ratings. 

5.  Add  the  resulting  scores  and  divide  each  score  by  the  resulting 
sum.  Round  to  two  decimal  places. 

Procedure  for  more  than  ten  activities: 

1.  Select  one  of  the  activities  at  random. 

2.  Randomly  assign  each  of  the  remaining  activities  to  groups  of 
approximately  equal  size,  with  no  more  than  five  activities  to 
a  group. 

3.  Add  the  activity  selected  in  (1)  to  each  group  and  assign  it 

a  rating  of  100.  This  "index"  activity  will  serve  to  link  each 
of  the  activity  clusters  later. 

4.  Rank  each  of  the  activities  within  each  group  in  order  of 
descending  importance.  Assign  numerical  ratings  to  each 
activity  following  the  procedure  outlined  for  ten  or  fewer 
activities.  Keep  the  rating  of  the  index  activity  fixed  at  100. 

5.  Merge  the  groups  to  form  one  consolidated  list  of  activities 
arranged  in  order  of  their  associated  importance  ratings. 

6.  Add  the  ratings  and  divide  each  by  the  resulting  sum.  Round 
to  two  decimal  places. 
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Step  5.  Review  DIFs  and  weight  them  according  to  their  importance 


There  are  four  primary  factors  on  which  each  design  concept  will  be 
valued.  Each  of  these  factors  is  divided  into  two  to  four  subordinate 
factors,  as  follows: 

1.  Personnel  —  how  many  and  what  kind  of  personnel  will  be  required 
to  man  each  design  concept  and  how  much  will  it  cost? 

a.  Quantity 

b.  Quality 

2.  Training  —  how  complex  will  the  training  development  be  and  how 
much  will  it  cost;  how  much  new  support  will  be  required  to  train 
personnel  and  how  much  will  it  cost;  how  much  time  will  be 
required  to  train  personnel  and  how  much  will  it  cost;  how 
risky  will  the  training  be? 

a.  Development 

b.  Delivery 

c.  Time 

d.  Risk 

3.  System  development  —  how  long  and  how  error  prone  is  system 
development  likely  to  be  and  how  much  will  it  cost;  how  much 
risk  is  involved  in  applying  the  particular  technology  and  how 
reliable,  available,  and  maintainable  will  the  technology  be 
when  it  is  developed  and  how  much  will  maintenance  cost;  how 
flexible  will  the  technology  be  for  accepting  upgrading  and 
how  much  will  upgrades  cost? 

a.  Time 

b.  Technological  risk 

c.  Flexibility/adaptability 

4.  System  performance  —  will  the  system  have  the  speed,  accuracy, 
and  capacity  (random  access  memory,  throughput,  secondary  memory, 
and  so  on)  required  of  it  as  specified  system  response  demands? 

a.  Speed 

b.  Accuracy 

c.  Capacity 

These  DIFs  are  not  necessarily  of  equal  importance.  If  they  are  not  of 
equal  importance,  they  need  to  be  assigned  differential  weights  that  will 
be  used  in  assigning  the  values  to  each  design  concept. 

The  differential  weights  are  obtained  by  ranking  the  factors  and 
assigning  ratings  to  them.  The  rankings  and  the  ratings  should  be  made 
by  stakeholders  from  each  of  the  areas  with  which  the  DIFs  are  concerned. 
Again,  a  group  method  which  mixes  these  two  kinds  of  specialists  in  inter¬ 
active  groups  for  obtaining  the  rankings  and  ratings  would  be  preferable. 


The  procedure  for  obtaining  DIF  weights  is  as  follows: 


1.  Rank  the  factors  at  each  level  of  the  hierarchy  and  in  each 
cluster  in  order  of  their  importance  to  the  design  problem  under 
consideration.  First,  rank  the  four  major  factors  (personnel, 
training,  system  development,  and  system  performance)  in  order 
of  importance.  Next,  rank  the  clusters  of  subordinate  factors 
under  each  major  factor.  For  instance,  rank  the  two  factors 
(quantity  and  quality)  under  the  personnel  factor.  Then  rank 
the  four  subordinate  factors  (development,  delivery,  time,  and 
risk)  under  the  training  factor.  Continue  in  this  way  until 
the  members  in  each  cluster  have  been  ranked. 

2.  Assign  ratings  within  each  level  and  cluster  in  the  hierarchy  as 
in  the  ranking  procedure  above. 

a.  Assign  the  least  important  factor  a  rating  of  10. 

b.  Consider  the  next-least-important  factor.  How  much  more 
important  is  it  than  the  least  important?  Assign  it  a 
number  that  reflects  that  ratio.  Continue  rating  in 
this  manner  until  all  factors  in  each  cluster  (including 
the  cluster  made  up  of  the  four  major  factors)  have  been 
rated.  Check  each  set  of  ratios  as  each  new  judgment 

is  made. 

c.  Review  your  ratings  to  insure  that  they  reflect  the 
importance  of  each  of  the  factors  and  subordinate  factors. 
Are  the  ratios  of  distances  between  factors  correct? 

Make  any  necessary  adjustments  to  your  ratings. 

d.  Normalize  the  values  within  each  cluster  (including  the 
cluster  made  up  of  the  four  major  factors)  by  summing 
the  ratings  and  dividing  the  individual  values  by  the 
result . 

3.  Obtain  an  aggregate  value  for  each  subordinate  factor  by 
multiplying  its  value  within  the  cluster  by  the  value  of  the 
major  factor  to  which  it  belongs. 


Step  6.  Obtain  ratings  for  each  information  processin 


design  concept  on  each  DIF 


activity  for  each 


At  this  state  in  the  analysis,  a  trade-off  matrix  having  dimensions 
defined  by  FATDS  design  concepts,  information  processing  activities,  and 
design  impact  factors  has  been  defined.  Figure  5  illustrates  the  form  of 
this  trade-off  matrox.  The  objective  of  Step  6  is  to  obtain  merit  ratings 
for  each  design  concept  for  each  information  processing  activity  on  each  DIF. 


The  merit  ratings  should  be  made  by  technical  experts  in  each  impact 
factor  area  and  technical  experts  in  the  respective  technologies  involved 
in  each  design  concept.  Since  it  is  unlikely  that  individuals  can  be  found 
who  possess  both  kinds  of  expertise,  the  ratings  should  be  obtained  by  using 
a  small  group  approach  in  which  each  group  is  made  up  of  different  kinds 
of  experts  as  required  for  the  particular  information  processing  activities 
and  design  concept  technologies  that  are  to  be  rated. 

For  this  first  level  of  analysis,  merit  ratings  can  be  made  on  a  l-to-3 
scale,  with  the  points  on  the  scale  defined  as  shown  in  Table  1.  The  unit 
of  the  system  that  is  rated  could  be  different  for  each  impact  factor,  but 
it  appears  that  system  component  may  constitute  the  most  useful  and  efficient 
unit.  Each  individual  system  component  usually  accounts  for  just  a  few  in¬ 
formation  processing  activities.  Oftentimes,  there  will  be  a  one-to-one 
match  between  components  and  activities.  Providing  ratings  at  the  component 
level  may,  however,  require  that  some  amount  of  preliminary  systems  organi¬ 
zation  (i.e.,  identifying  information  processing  activities  with  distinct 
system  elements)  be  carried  out. 


Step  7.  Obtain  partial  FOM  on  each  DIF  for  each  design  concept 

In  this  step,  calculate  a  partial  FOM  for  each  design  concept  for  each 
primary  DIF.  A  partial  FOM  is  obtained  by,  first,  aggregating  merit  ratings 
acrosss  information  processing  activities  within  each  subordinate  DIF: 


PMik(j)  l  Wi  Riik(j)' 


,th 


(1) 


concept  alternative 


In  (1),  PM  ...  denotes  the  partial  merit  (PM)  of  the  Z1 
on  the  k  subordinate  DIF  (nested  under  the  j  primary  DIF) ;  represents 
the  importance,  or  criticality,  of  the  i  information  processing  activity; 

and  R  ...  is  the  merit  rating  (l-to-3)  assigned  the  concept  alternative 

j '  tli  th 

on  the  i  activity  for  the  k  subordinate  DIF  (under  the  j  primary  factor), 


Partial  FOMs  for  the  primary  DIFs  on  each  alternative  hre  obtained  by 
aggregating  merit  indices  across  subordinate  DIFs.  That  is, 


P\i  =  l  Dk(j)  PMik(j)* 


(2) 


where  D 
,  th 


k(j) 


represents  the  importance  of  the  k^  subordinate  DIF  nested  under 


the  j  primary  factor.  All  other  terms  are  as  defined  previously. 
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Table  1 

Concept-Level  Rating  Anchor  Points 


A.  Personnel 

a. 1.  Quantity : 

1  -  The  number  of  personnel  required  to  operate  and  maintain 

this  alternative  will  be  high,  relative  to  the  antecedent 
(or  baseline)  system. 

2  -  Personnel  requirements  will  be  approximately  the  same  as 

the  antecedent  system. 

3  -  Personnel  requirements  will  be  less  than  the  antecedent  system. 

a.  2.  Quality: 

1  -  The  personnel  required  to  operate  and  maintain  this  alternative 

must  be  of  higher  quality  than  the  antecedent  system. 

2  -  Personnel  quality  requirements  will  be  approximately  the 

same  as  the  antecedent  system. 

3  -  Personnel  quality  requirements  will  be  less  than  those  of 

the  antecedent  system. 

B.  Training 

b. l.  Development: 

1  -  Training  development  on  this  alternative  will  be  a  complex 

undertaking.  Extensive  and  detailed  front  end  analyses 
will  be  required. 

2  -  Training  development  for  this  alternative  will  not  be 

appreciably  more  complex  than  for  similar  systems  of  this  type. 

3  -  Training  development  will  be  a  relatively  easy  process. 

The  new  system  is  very  similar  to  its  predecessor,  or 
conceptually  similar  systems  exist  elsewhere. 

b.2.  Delivery: 

1  -  The  training  delivery  system  will  be  complex  and  extensive. 

It  will  require  the  construction  of  many  new  facilities. 

2  -  The  training  delivery  system  for  this  alternative  will  not  be 

appreciably  more  complex  or  extensive  than  for  similar  or 
antecedent  systems. 

3  -  The  training  delivery  system  for  the  antecedent  can  be  used 

almost  "as  is". 

b.3.  Time: 

1  -  The  time  required  to  train  personnel  to  operate/maintain  this 

alternative  will  be  considerably  longer  than  the  antecedent  system. 

2  -  The  time  required  to  train  personnel  to  operate/maintain  this 

alternative  will  be  approximately  the  same  as  the  antecedent 
system. 

3  -  Less  time  will  be  required  for  training  this  system  than  is 

required  on  the  antecedent  system. 
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Table  1  (Coat'd) 


b. 4.  Risk: 

1  -  Given  the  anticipated  personnel  input  to  the  training 

program  and  the  allocated  training  time,  there  is  con¬ 
siderable  risk  that  training  objectives  will  not  be  met. 

2  -  Training  risk,  measured  in  terms  of  the  likelihood  of 

meeting  training  objectives,  is  approximately  the  same 
for  this  alternative  as  on  other  systems  that  are  similar 
in  concept. 

3  -  There  is  a  high  likelihood  of  being  able  to  meet  training 

objectives . 

C.  System  Development 

c .  1 .  Time : 

1  -  The  alternative  under  consideration  represents  a  considerable 

departure  from  the  antecedent  system.  Hence,  there  is  a  high 
likelihood  that  the  system  development  process  will  be  Ion;; 
and  possibly  error-prone. 

2  -  The  alternative  is  relatively  complex,  but  does  not  represent 

a  significant  departure  from  the  antecedent  system.  N'o  real 
problems  in  the  system  development  process  are  anticipated. 

3  -  The  technology  involved  in  this  alternative  is  "off-the-shelf." 

System  development  time  should  be  shorter  than  usual. 

c.2.  Technological  Risk: 

1  -  The  technology  employed  in  this  alternative  is  beyond  the 

current  state  of  the  art.  There  is  considerable  risk 
involved  in  taking  this  approach. 

2  -  The  technology  employed  in  this  alternative  represents  the 

state  of  the  art.  Some  modifications  may  be  in  order,  but 
no  real  problems  are  foreseen. 

3  -  The  technology  employed  in  this  alternative  is  off-the-shelf. 

It  has  been  proven  in  a  variety  of  similar  applications. 

c.3.  Flexibility /Adaptability : 

1  -  It  will  not  be  possible,  beyond  a  very  limited  scope,  to 

modify  this  alternative  to  meet  changing  threat / technological 
situations . 

2  -  The  technology  used  in  this  alternative  will  not  be  particularly 

amenable  to  change.  PIPs  will  require  significant  hardware 
modi f ications . 

3  -  The  technology  used  in  this  alternative  will  result  in  a  very 

flexible  and  adaptative  system;  it  will  be  possible  to 
accomplish  system  upgrades  (i.e.,  PIPs)  without  completely 
redesigning  or  reconfiguring  the  system. 
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Table  1  (Cont'd) 


D.  Performance — likelihood  of  meeting  system  response  demands 
d.l.  Speed: 

1  -  System  response  demands  will  not  be  met.. 

2  -  System  response  demands  will  be  met,  but  not  exceeded. 

3  -  System  response  demands  will  be  exceeded. 

d.2.  Accuracy: 

1  -  System  requirements  will  not  be  met. 

2  -  System  response  demands  will  be  met,  but  not  exceeded. 

3  -  System  response  demands  will  be  exceeded;  alternative 

is  not  error-prone. 

d. 3.  Capacity: 

1  -  The  capacity  of  this  alternative  is  not  sufficient  to 

meet  the  present  and  the  near-term  future  threat. 

2  -  The  capacity  of  this  alternative  is  adequate  to  meet  the 

present  and  near-term  future  threat. 

3  -  The  capacity  of  this  alternative  (e.g.,  random  access  memory, 

throughput,  secondary  memory,  etc.)  exceeds  that  required  to 
meet  the  current  and  near-term  future  threat. 
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Users  also  can  compute  partial  FOMs  for  each  of  the  m  system  com¬ 
ponents  by  aggregating  merit  ratings  across  DIFs  within  components.  This 
would  be  done  by,  first,  aggregating  across  transactions  within  components 
and  then  aggregating  across  subordinate  and  primary  DIFs: 

PM  =  E  {  E  D.  W.  K  ...  ]  }  (3) 

m  k(j)  t(m)  £.1  (m)k  (j ) 

J  K  1 

In  (3),  indicates  the  criticality  of  the  i^1  IP  activity  within  the 

m^  system  component,  and  D  . ..  again  represents  the  importance  of  the  k1^' 

'3  f  t h 

subordinate  DIF  nested  under  the  ]  primary  factor. 


Step  8.  Obtain  aggregate  FQM  for  e_ach__des i gn  c on c o p t 

An  aggregate  FOM  for  each  concept-level  alternative  is  obtained  by 
aggregating  partial  FOMs  across  DIFs: 

Mf  =  s  p v  <4> 

J 

The  concept  alternative  having  the  highest  aggregate  FOM  is  preferred. 
Hence,  it  is  the  alternative  to  select  for  additonal  development.  If  no 
single  design  concept  yields  a  FOM  significantly  higher  than  the  rest,  then 
the  two  highest  scoring  alternatives  should  be  carried  forward  into  the 
next  step. 


Step  9.  Review  the  results  of  the  two  previous  steps  in  an  attempt  to 
improve  the  highest  rated  design  concept 

The  design  concept  with  the  most  favorable  FOM  is  selected  for  review 
and  improvement.  First  of  all,  users  should  identify  its  least  favorable 
components  and  DIFs.  Compare  these  ratings  with  similar  ratings  obtained 
for  the  other  design  concepts.  Can  parts  of  other  design  concepts  be  sub¬ 
stituted  into  the  preferred  design,  thus  increasing  the  FOM  for  the  selected 
design?  If  so,  make  the  substitutions  and  calculate  new  FOMs. 

If  two  design  concepts  were  carried  into  this  step,  then  perform  the 
above  procedure  on  both  of  them  to  determine  whether  substantially  different 
FOMs  result.  If  so,  then  carry  the  one  with  the  higher  value  into  the  next 
phase.  However,  if  the  two  design  concepts  still  do  not  yield  substantially 
different  FOMs,  then  carry  both  of  them  forward  into  the  next  phase. 

Finally,  revise  the  parallel  flowcharts  for  the  selected  design  concepts 
as  they  were  developed  in  Step  3  of  Phase  3  of  the  front-end  analysis.  Re¬ 
vised  flowcharts  are  necessary  in  the  next  phase. 
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PHASE  TWO: 


DEVELOP  ALTERNATIVE  INTERFACE  CONCEPTS  FOR  THE  SELECTED  AND 
REVISED  DESIGN  CONCEPT 


Phase  2  develops  several  alternative  Interface  concepts  for  the 
selected  and  revised  design  concept,  evaluates  each  interface  concept, 
and  revises  the  best  of  the  interface  concepts  in  an  effort  to  improve 
it.  The  interfaces  between  human  and  machine  exist  to  facilitate  trans¬ 
actions  of  information  from  one  to  the  other.  The  critical  aspect  in 
designing  interfaces  for  C^  systems  is  to  insure  that  the  interfaces  select, 
organize,  display,  and  accept  information  in  such  a  manner  as  to  facilitate 
the  natural  information  processing  activities  of  the  commanders/operators 
of  the  system.  With  regard  to  control  room  operators  for  large  industrial 
processes,  Rasmussen  and  Lind  (1981)  observe: 

The  operator's  symbolic  data  processing. . .depends  upon  an 
internal  or  mental  model  of  the  causal  structure  of  the 
system,  and... humans  have  a  number  of  ingenious  ways  to 
circumvent  complexity  by  transfer  of  the  problem  to  a 
representation  suited  to  treat  the  present  problem. . . 

The  major  tools  are  hierarchical  aggregation/decomposition 
to  change  the  resolution  of  the  attention  applied  to  the 
problem — which  is  very  often  coupled  to  a  change  in  level 
of  abstraction  used  for  the  causal  representation... 

Hierarchical  decomposition/aggregation  is  related  to  the 
span  of  attention  of  the  operator  (and)  to  the  level  of 
detail  or  resolution  applied  for  data  processing. 

With  regard  to  the  general  cognitive  model  for  monitoring  remote  systems 
described  in  Phase  3  of  the  front-end  analysis,  aggregation  occurs  pri¬ 
marily  on  the  input  branch  and  decomposition  occurs  primarily  on  the  output 
branch.  The  level  of  abstraction  to  which  aggregation  is  carried  and  from 
which  decomposition  begins  is  determined  by  the  operator's  processing  of 
the  information  to  arrive  at  a  response  alternative.  However,  there  may 
well  be  many  fluctuations  in  the  level  of  abstraction  in  the  commander/ 
operator's  internal  information  processing  between  the  initial  aggregation 
branch  and  the  final  decomposition  branch.  The  commander/operator  may 
first  scan  a  broadscale  internal  representation  of  the  situation,  examine 
one  or  two  more  detailed  levels  of  representation  of  parts  of  the  situation, 
recall  a  menu  of  broad  options  and  principles  for  selecting  from  them, 
make  a  selection,  and  then  recall  specific  details  at  two  or  three  lower 
levels  to  implement  the  selected  option.  If  the  displays  which  he  receives 
from  the  interfaces  do  not  match  his  internal  processing,  he  may  be  momentarily 
confused  and  may  have  to  undertake  several  additional  mental  actions  either 
to  transform  the  display  representations  to  match  his  own  or  transform  his 
own  to  match  the  display.  In  either  case,  he  loses  time  and  may  also  lose 
continuity  in  his  own  internal  processing.  Transforming  representations 
to  make  them  fit  each  other  may  well  be  too  complex  a  task  within  the  overall 
context  of  the  other  activities  he  has  to  perform.  Rasmussen  and  Lind  (1981) 
observe : 
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The  way  to  assist  operators  to  avoid  complexity  is... to  make 
a  repertoire  of  display  formats  available  to  him,  structured 
in  a  hierarchy  with  a  small  number  at  the  high  levels  of 
abstraction/aggregation,  and  a  larger  number  at  the  low  detailed 
levels,  together  with  an  orderly  and  structured  way  to  seek 
through  the  hierarchy  to  "zoom-in"  on  the  relevant  display. 

The  properties  of  the  individual  displays  and  the  quality  of 
cross-references  to  related  displays  at  higher  and  lower  levels 
of  abstraction  are,  however,  important  for  the  perception  of 
complexity . 

The  symbols  used  for  displaying  information  also  are  critical.  If  the 
commander/operator's  internal  representation  is  primarily  spatial  and  the 
interface  displays  are  alphanumeric,  the  display  information  will  have  to 
be.  transformed  before  it  can  he  related  to  the  individual's  internal  spatial 
representation.  In  such  an  instance,  graphic  displays  at  the  appropriate 
level  of  detail  might  be  much  more  readily  usable  by  the  commander/operator. 
Both  the  speed  and  the  accuracy  of  response  might  be  enhanced  by  graphic 
displays  . 

Equal  attention  must  be  paid  to  the  design  of  the  information  repre¬ 
sentation  in  the  controls  as  is  paid  to  the  design  of  the  displays.  The 
problems  of  obtaining  an  adequate  fit  between  the  commander /operator ' s 
internal  representations  and  the  representations  in  the  controls  are 
similar.  If  the  commander/operator's  internal  representations  of  response 
alternatives  are  abstract  and  spatial  but  the  control  representations  are 
detailed  and  alphanumeric,  then  the  individual  must  engage  in  a  series  of 
potentially  disruptive  transformati  -.ns  . 

Wherever  possible,  the  interface  designs  should  minimize  the  percep¬ 
tion  of  complexity  and  the  transformations  required  of  commander/operators 
It  may  be  necessary  to  add  new  information  processing  activities  to  the 
machine  components  of  the  system  to  develop  the  appropriate  levels  and 
symbols  for  presenting  information  to  commander/operators  and  for  accepting 
information  from  them. 

Phase  2  consists  of  ten  steps,  as  follows: 

1.  Identify  all  human/machine  and  machine/human  transactions  in 
the  revised  flowcharts  for  the  selected  design  concept. 

2.  Identify  and  describe  the  commander/operator's  general 
cognitive  context  for  each  transaction. 

3.  Develop  the  machine  technology  focus  for  each  interface  concept. 

4.  Develop  alternative  interface  concepts  for  each 
commander /operator  position. 
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5.  Determine  the  importance  of  each  transaction  to  the  attainment 
of  field  artillery  objectives  (missions). 

b.  Review  the  DIFs  and  weight  them  according  to  their  importance. 

7.  Obtain  ratings  for  each  transaction  (T)  in  each  interface 
concept  on  each  DIF. 

8.  Obtain  partial  FOMs  on  each  DIF  for  each  interface  concept. 

9.  Obtain  aggregate  FOM  for  each  interface  concept. 

10.  Review  the  results  of  the  two  previous  steps  in  an  attempt 
to  improve  the  highest  rated  interface  concept. 

The  outcome  of  this  phase  is  a  specification  of  those  technologies  that 
provide  the  best  information  representations  at  each  interface  for  accomplish¬ 
ing  each  transaction. 


Step  1.  Identify  all  human/machine  and  machine/human  transactions  in  the 
revised  flowcharts  for  the  selected  design  concept 

The  design  concept  is  specified  in  part  by  one  or  more  parallel  flow¬ 
charts  in  which  each  system  component  (including  the  human  subsystem)  is 
represented  by  one  row  in  the  flowchart.  Human/machine  and  machine/human 
transactions  are  represented  as  flow  lines  which  cross  the  boundaries  of 
the  human  subsystem  row,  either  originating  from  or  terminating  in  an  in¬ 
formation  processing  activity  in  the  human  subsystem  row.  Each  such  trans¬ 
action  should  be  identified  and  designated  in  one  of  two  lists,  one  for 
human/machine  transactions  (for  interface  controls)  and  one  for  machine/ 
human  transactions  (for  interface  displays).  The  designation  of  each 
transaction  should  specify  the  originating  IP  activity,  the  terminating  IP 
activity,  the  system  component  that  performs  each  activity,  and  the  mission 
context  within  which  each  activity  occurs. 


Step  2.  Identify  and  briefly  describe  the  commander/operator's  general 
cognitive  context  for  each  transaction 

In  this  step,  the  cognitive  processes  of  the  commander/operator  sur¬ 
rounding  each  transaction  are  briefly  described.  What  kinds  of  cues  are 
presented  to  indicate  to  the  commander/operator  that  he  needs  to  perform 
a  given  transaction?  What  kinds  of  cues  shape  his  performance  of  each 
transaction?  What  kinds  of  cues  serve  as  feedback  regarding  the  adequacy 
of  a  given  transaction?  What  kinds  of  decisions  are  to  be  made  either 
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directly  before  or  directly  after  each  transaction,  if  any?  What  kind  of 
information  must  be  presented  to  the  commander/operator?  What  short  and 
long  term  memory  requirements  are  imposed  on  the  commander /operator?  How 
large  a  cognitive  load  must  he  be  able  to  handle?  What  is  the  rate  at  which 
transactions  must  occur?  At  what  level  of  abstraction  and  in  what  symbols 
are  relevant  information  and  applicable  principles  represented  in  the 
commander/operator's  internal  information  processing?  These  descriptions 
should  be  developed  by  personnel  who  have  had  the  most  extensive  experience 
in  commanding  and  operating  existing  FATDS  in  combat  or  near-combat-like 
situations.  However,  they  will  need  more  than  just  their  experience  as  a 
basis  for  generating  the  descriptions.  They  should  also  be  provided  with 
a  summary  of  the  system  response  demands  and  a  summary  of  the  selected  epi¬ 
sode  descriptions  from  the  front-end  analysis  and  time  in  which  to  review 
them  thoroughly.  Use  a  group  process  to  develop  the  descriptions. 

Sort  the  transactions  into  categories  according  to  the  commander/operator 
position  at  which  they  are  to  be  performed.  Prepare  a  summary  of  the  trans¬ 
action  descriptions  in  each  category.  These  summaries  identify  the  cognitive 
contexts  relevant  to  each  interface  and  constitute  the  basic  performance  re¬ 
quirements  for  each  interface. 


Step  3.  Develop  the  machine  technology  focus  for  each  interface  concept 

The  same  approach  is  used  in  this  step  as  was  used  in  the  first  step  of 
the  previous  phase  for  developing  alternative  design  concepts.  However,  in 
this  case  the  interface  technologies  must  be  compatible  with  the  machine 
technologies  selected  for  information  processing  in  the  selected  design  con¬ 
cept.  Again,  alternative  interface  concepts  for  the  selected  design  concepts 
are  developed  to  address  at  least  three  different  levels  of  interface  technology 

1.  Existing  technologies.  The  interface  concept  at  this  level 
will  draw  only  from  those  compatible  interface  technologies 
that  are  fully  developed  and  on  the  commercial  market  at  this 
time . 

2.  State-of-the-art  technologies.  The  interface  concept  at  this 
level  will  draw  not  only  from  existing  interface  technologies 
but  also  from  those  technologies  whose  potential  has  been  proven 

in  research  applications  and  perhaps  in  some  prototype  applications, 
but  they  are  not  yet  widely  available  commercially. 

3.  Foreseeable  technologies.  The  interface  concept  at  this  level 
will  draw  not  only  from  existing  and  state-of-the-art  technologies, 
but  also  from  technologies  that  are  theoretically  feasible  but 
which  have  not  been  tested  in  any  applications. 
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Using  these  definitions  as  a  guide,  examine  the  transaction  description 
summaries  for  each  commander/operator  interface  position  and  identify  the 
interface  technologies  that  will  provide  the  closest  match  to  the  cognitive 
context  in  the  summaries  at  each  level  of  focus.  There  may  well  be  several 
technologies  at  the  same  level  of  focus  that  apply  to  the  same  character¬ 
istics  in  a  given  summary.  At  this  point,  list  them  all.  Again,  the 
persons  who  make  these  judgments  should  be  the  most  knowledgeable  avail¬ 
able  with  regard  to  the  various  interface  technologies.  As  before,  if  the 
experts  can  be  assembled  in  small  groups,  then  a  group  process  should  be 
used  to  obtain  their  judgments.  If  they  cannot  be  assembled  at  one  place 
at  one  time,  then  a  Delphi  approach  would  be  useful. 

Step  4.  Develop  alternative  interface  concepts  for  each  commander/operator 
position 

Before  interface  arrangements  can  be  conceived,  it  is  necessary  to 
decide  which  performance  characteristics  are  important  for  each  interface. 

In  some  instances,  the  speed  and  accuracy  with  which  the  operator  extracts 
information  from  the  displays  or  enters  decisions  into  the  controls  may  be 
critical.  In  other  instances,  his  speed  and  accuracy  in  searching  through 
an  aggregation/decomposition  hierarchy  may  be  critical.  Speed  and  accuracy 
standards  specify  how  well  the  operator  must  perform.  It  is  also  necessary 
to  specify  what  the  interface  can  do  to  support  the  operator,  and  the  inter¬ 
face  characteristics  that  are  most  directly  responsible  for  providing  that 
support;  for  example,  level  of  abstraction  and  symbols  used  for  presenting 
information,  minimum  information  clutter,  interface  response  time  to  inputs 
or  requests  for  other  information.  A  specification  of  these  kinds  of  char¬ 
acteristics  should  be  prepared  for  each  interface. 

An  interface  concept  consists  of  a  tentative  arrangement  of  displays 
and  controls;  a  specification  of  the  information  content,  levels  of  abstrac¬ 
tion,  and  symbols  which  characterize  the  displays  and  controls;  a  specifica¬ 
tion  of  the  hardware  and/or  software  technologies  to  be  used  in  the  interface; 
a  specification  of  the  speed  of  response  available  in  display  changes  and  in 
controls.  Other  characteristics  may  well  become  apparent  once  a  few  interface 
concepts  are  prepared.  The  alternative  interface  concepts  should  provide 
sufficient  specification  to  prepare  full  scale  two  dimensional  mock-ups  of 
the  various  interface  panels  and  to  prepare  input  displays  and  control  feed¬ 
back  displays  involved  in  actually  performing  the  transactions  involved  in  a 
particular  episode. 

Step  5,  Determine  the  Importance  of  each  transaction  to  the  attainment  of 
field  artillery  objectives  (mis s Ions ) 

Some  transactions  are  more  important  for  accomplishing  the  objectives  of 
the  field  artillery  system  than  are  others.  Consequently,  it  is  necessary  to 
assign  each  transaction  a  value  that  reflects  its  criticality  for  accomplish¬ 
ing  field  artillery  missions,  as  was  done  in  Step  5  of  Phase  1  of  this  stage. 


The  mission  criticality  judgments  should  be  made  by  those  available 
personnel  who  have  had  the  most  intensive  experience  in  commanding  and 
operating  existing  FATDS  in  the  most  combat-like  situations  possible.  How¬ 
ever,  raters  will  need  more  than  just  their  experience  in  judging  criticality 
They  should  be  provided  with  a  summary  of  the  transaction  performance  re¬ 
quirements  and  a  summary  of  the  selected  episode  descriptions  from  the 
front-end  analysis  and  time  in  which  to  review  them  thoroughly.  Again,  if 
possible,  use  a  group  process. 

There  are  two  different  procedures  that  can  be  used  in  obtaining  the 
criticality  judgments.  They  were  previously  described  in  Step  4  of  the 
first  phase  of  the  design  process.  The  ratings  for  IP  activities  assigned 
in  Phase  1  might  also  be  useful  in  providing  importance  ratings  for  IP 
transactions . 


Step  6.  Review  the  DIFs  and  weight  them  according  to  their  importance 

The  DIFs  used  to  value  the  interface  concepts  are  essentially  the  same 
as  those  used  to  value  the  design  concepts  as  described  in  Step  5  of  the 
first  phase  of  this  stage.  However,  the  weights  assigned  to  the  DIFs  need 
not  be  the  same  as  the  weights  assigned  to  them  in  the  previous  phase.  In 
fact,  it  may  be  desirable  to  revise  the  DIFs  or  their  definitions.  Some 
DIFs  might  be  eliminated  as  not  relevant  for  valuing  the  alternative  inter¬ 
face  concepts.  For  instance,  it  seems  reasonable  that  the  weights  obtained 
previously  for  personnel  and  training  factors  may  still  be  appropriate,  but 
that  new  weights  might  be  desired  for  the  development  and  performance  factors 


Step  7.  Obtain  ratings  for  each  transaction  (T)  on  each  interface  concept 
on  each  DIF 


The  next  step  in  the  procedure  concerns  obtaining  merit  ratings  for 
the  interface  alternatives  for  each  transaction  and  on  each  DIF.  These 
ratings  should  be  made  by  technical  experts  in  each  impact  factor  area, 
by  technical  experts  in  the  respective  technologies  involved  in  each  inter¬ 
face  concept,  and  by  the  most  experienced  personnel  available  in  commanding 
or  operating  FATDS.  Since  it  is  unlikely  that  individuals  can  be  found  who 
possess  all  three  kinds  of  expertise,  the  ratings  should  be  obtained  by 
using  a  small  group  approach  in  which  each  group  is  made  up  of  different 
kinds  of  experts  as  required  for  the  particular  interface  concept  that  is 
to  be  rated.  During  these  ratings,  the  raters  should  have  available  to 
them  the  specifications  for  the  interface  concept  being  rated,  full-scale 
tentative  mock-ups  of  the  interface  panels,  and  complete  sets  of  examples 
of  the  information  characteristics  of  the  displays  and  controls  required 
for  performing  the  transactions  in  the  selected  episodes  from  the  front-end 
analysis.  They  should  also  have  the  summaries  of  the  episodes  from  the 
front-end  analysis.  Part  of  their  judgment  process  may  well  involve 
walking-through  and  talking-through  many  of  the  transactions. 
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Since  interface  characteristics  per  se  are  less  ambiguous  than  the 
properties  of  the  concept-level  alternatives,  the  experts  are  asked  to 
provide  merit  ratings  on  a  0-to-100  scale.  The  following  scale  anchors 
can  be  used  as  a  guide  in  assigning  interface  merit  ratings: 


0  - 

the 

alternative 

is 

completely  unacceptable 

for  this 

application. 

25  - 

the 

alternative 

is 

marginally  acceptable  for  this 

application . 

50  - 

the 

alternative 

is 

judged  adequate  for  this 

application 

75  - 

the 

alternative 

is 

judged  to  be  an  above  average  choice 

for 

this  application. 

100  - 

the 

alternative 

is 

the  best  possible,  given 

the  current 

and 

anticipated 

state-of-the-art . 

The  unit  of  the  system  that  is  judged  this  time  consists  of  an  entire 
interface  for  a  position,  or  of  the  different  parts  of  an  interface  if  they 
are  used  for  totally  separate  transactions.  Step  7  results  in  an  interface 
trade-off  matrix  of  order  i^  transactions  by  j.  DIFs  by  Z  interface  alterna¬ 
tives.  The  objective  of  the  remaining  steps  is  to  integrate  the  information 
in  the  trade-off  matrix  so  that  a  decision  can  be  made  concerning  a  preferred 
interface  configuration. 


Step  8,  Obtain  partial  FOMs  on  each  DIF  for  each  interface  concept 

In  Step  8,  partial  FOMs  for  each  alternative  on  each  subordinate  and 
primary  DIF  and  for  each  system  component  are  computed.  The  procedures 
used  to  obtain  the  various  FOMs  are  nearly  identical  to  those  used  in  Step  7 
of  the  previous  phase.  These  are  recapped  briefly  as  follows. 


1.  Obtain  a  partial  FOM  for  each  interface  alternative  on  each 
subordinate  DIF: 

PMtk(j)  '  P  Wi  RUk(j)’  <5> 

where  is  the  importance  of  the  i^  information  processing 
transaction,  and  all  other  terms  are  analogous  to  those  defined 
previously. 


2.  Obtain  a  partial  FOM  for  each  alternative  on  each  of  the  lc 
primary  DIFs: 


PM 


a 


=  Z 


Dk(j)  PM&k(j )  ’ 


(6) 
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3.  Obtain  a  partial  FOM  tor  each  of  the  m  system  components: 


PM  =  E  {5:  D,  ...  [E  W.  .  .  R.  }. 

m  j  k  i  *-i(m)k.(j) 


Step  9.  Obtain  aggregate  FOM  for  each  alternati ve  interface  concept 


In  Step  9,  aggregate  FOMs  for  each  interface  alternative  are  obtained 
by  summing  partial  FOMs  across  primary  DIFs: 


►v  -  £  PHtj.  (8) 

J 

The  interface  alternative  with  the  highest  aggregate  FOM  is  preferred;  it 
is  the  interface  configuration  to  select  for  development.  If  no  single 
interface  alternative  yields  a  substantially  higher  value  than  the  others, 
then  the  two  highest  ones  should  be  carried  forward  into  the  next  step  where 
a  final  determination  will  be  made. 


Step  10,  Review  the  results  of  the  two  previous  steps  in  an  attempt  to 
improve  the  highest  rated  interface  concept 


The  interface  alternative  with  the  highest  aggregate  FOM  is  selected 
for  review  and  improvement.  Again,  identify  its  least  favorable  transac¬ 
tions  or  transaction  sets,  components,  and  DIFs.  Compare  these  ratings  with 
similar  ratings  obtained  for  the  competing  interface  concepts.  Can  parts 
of  other  interface  concepts  be  substituted  into  the  selected  concept  thus 
increasing  the  FOM  for  the  selected  interface?  If  so,  make  the  substitutions 
and  calculate  new  figures  of  merit. 


If  several  alternative  interface  concepts  are  carried  into  this  step, 
then  perform  the  above  procedure  on  both  to  determine  whether  substantially 
different  aggregate  FOMs  result.  If  so,  then  select  the  one  with  the  highest 
value  for  implementation.  However,  if  the  alternative  interface  concepts 
still  do  not  yield  substantially  different  overall  values,  then  the  selection 
will  have  to  be  made  at  a  higher  level  using  additional  and  perhaps  more  sub¬ 
jective  decision  factors. 
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GENERAL  CHARACTERISTICS  AND  BENEFITS  OF  THE  CDMA 


The  Concept  Design  Management  Approach  (CDMA)  provides  the  develop¬ 
mental  context  and  procedures  for  conducting  trade-off  analyses  of  al¬ 
ternative  concept  designs  for  a  C3  system  and  for  integrating  the  better 
features  of  the  non-selected  alternatives  into  the  selected  alternative. 

The  approach  is  characterized  by  eleven  significant  features: 

1.  It  is  a  rational  approach  for  developing  the  design  concept 
for  a  FATDS.  It  consists  of  two  major  processes: 

a.  A  front  end  analysis  process  (1)  which  collects  or  generates 
information  about  the  environments  and  situations  in  which 
the  FATDS  will  operate,  (2)  which  identifies  the  response 
demands  which  must  be  met  by  the  FATDS,  and  (3)  which 
specifies  the  minimum  human  role  which  must  be  supported 

by  the  system. 

b.  A  design  concept  process  (1)  which  allocates  information 
processing  activities  in  the  emerging  system  concept  to 
human  or  machine  components  and  (2)  which  specifies  the 
interface  characteristics  required  to  support  mental 
information  processing  of  commanders  and  operators  of  the 
FATDS. 

2.  It  conceives  of  a  FATDS  (or  any  C3  system)  as  being  an  information 
processing  system  performed  both  by  machine  and  human  components. 

3.  It  provides  a  general  cognitive  model  for  insuring  at  least  a 
minimum  role  for  humans  as  commander/monitor  of  the  system. 

This  model  provides  guidance  for  analyzing  the  activities 
which  make  up  this  role. 

4.  It  encourages  the  consideration  of  established  technologies, 
state-of-the-art  technologies,  and  foreseeable  technologies 
to  insure  that  the  resulting  system  concept  is  not  outmoded 
by  the  time  the  system  is  fielded. 

5.  It  identifies  the  various  kinds  of  human  judgments  that  need 
to  be  made  in  developing  a  design  concept  for  a  FATDS. 

6.  It  identifies  the  characteristics  of  personnel  best  suited  for 
making  each  kind  of  judgment. 
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7.  It  specifies  particular  group  process  techniques  for  obtaining 
the  best  possible  judgments  from  the  appropriate  personnel. 

These  techniques  provide  for  the  mixing  of  personnel  with 
different  qualifications  in  each  group  so  that  each  can  bring 
his  or  her  own  special  qualifications  to  bear  on  the  judgments 
in  an  optimum  manner. 

8.  It  specifies  techniques  for  assigning  numeric  values  to  judgments 
and  for  aggregating  judgments  from  different  raters.  The 
aggregation  procedures  allow  for  the  introduction  of  differ¬ 
ential  weights  which  reflect  management  interests  and  criteria. 

9.  It  specifies  trade-off  techniques  for  using  the  numberic  values 
assigned  to  judgments  regarding  the  impact  of  alternative 
concepts  on  critical  factors  for  selecting  the  best  of  several 
alternative  design  or  interface  concepts. 

10.  It  specifies  techniques  for  using  the  numeric  values  assigned 
to  judgments  regarding  the  impact  of  a  design  or  interface 
concept  on  critical  factors  for  improving  the  concept. 

11.  It  provides  a  basis  for  developing  a  detailed  audit  trail  of 
the  entire  design  concept  process. 

The  approach  described  in  this  report  offers  the  design  management 
team  a  number  of  attractive  benefits: 

1.  It  provides  a  rational  and  fully  described  approach  which  can 
either  be  incorporated  into  the  project  intact  or  used  as  a 
first  approximation  in  developing  their  own  fully  explicated 
approach.  The  CDMA  is  very  flexible  and  can  be  readily  adapted 
to  meet  specialized  needs  and  interests. 

2.  It  provides  a  division  of  activities  that  can  be  used  for 
measuring  progress  and  making  assignments. 

3.  It  provides  a  basis  for  project  stability  even  through  major 
personnel  changes.  New  personnel  can  readily  review  the  audit 
trail  of  past  activities  and  the  projection  of  future  activities. 

4.  It  provides  assurance  that  the  design  concept  that  evolves  from 
the  application  of  the  approach  is  the  best  that  could  be 
developed  at  that  time  with  the  personnel  and  resources 
available. 

At  this  time,  the  CDMA  exists  more  as  a  very  detailed  proposal  since  it 
has  not  actually  been  tried  out  as  an  intact  process.  A  tryout  would  help 
develop  or  firm  up  details  in  the  process.  However,  all  of  its  features 
are  drawn  from  established  behavioral  science  technology.  There  is  no  doubt 
about  it  being  a  workable  process,  but  adjustments  will  be  needed  during 
its  early  applications. 
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